Official Release - CMOS

Chris Gransden has a point in that some of this argument is redundant now that PackMan can move the installation location of packages, eliminating the need for stubs. (WTF was the guy who invented those thinking? Actually, don’t answer that, because I directly asked him what he was thinking a couple of years ago. The answer made as much sense as you might expect.)

I expect it made a lot of sense, you just didn’t agree with what he was saying.

Let's study a few selected quotes from a 2010 email conversation with Graham Shaw, shall we?

Comparable situation with GNU/Linux. When it was normal practice to compile from source, people installed more or less wherever they wanted. When you start using a package manager, you just don't do that.

As on GNU/Linux, package management works just fine when used as intended, but if you try to fight it then it is liable to fight back.

My personal experience is that the urge to tinker soon passes after you've had to reinstall a few times.

I fully agree that the nature of RISC OS demands more flexibility than Linux, however there is a difference between flexibility and anarchy.

It may be worth asking whether a package manager is really the right solution to your requirements. An installer would be much simpler, and probably much faster too.

Just like a flesh-and-blood manager, there's no point employing one unless you are prepared to delegate most of the detailed decision-making and switch your attention to setting high-level strategy. I'm not saying you shouldn't be able to step in and override it occasionally, but if you're doing that as a matter of course then it probably isn't the right tool for you.

These were mostly in the context of trying to persuade him that catering for the possibility of users moving installed applications might be a good idea. This was before I fully appreciated the ramifications of having the manager automatically dump stuff in a fixed location in the first place.

Anyway, to cut a long story short, it didn't happen. I hope it is now somewhat clearer why, and on what basis, I believe that the design of LibPkg was slavishly copied from Linux without sufficient regard for how that system differs at both a technical and a cultural level from RISC OS.

Well the locations are not random, they’ve been considered by the application authors.

That is exactly the same thing. They've been considered... by many very different application authors, each of whom have very different ideas of how things should be done, and different ideas about how RiscPkg works and what it's for, and different ideas about how the English language works. With minimal central coordination. Have you considered taking up a position herding cats instead? You might find it easier.

Also...

Cut down that ridiculous list of categories! And take a leaf out of !Store’s very sensible book and allow packages to be filed under more than one, because really, trying to slice reality into that many discrete non-overlapping black and white chunks is inviting chaos and confusion.

Reasonable suggestions, I haven’t any plans to fix this though, Sections are decided by Package authors using the guidance of the Policy Manual and not really under my control.

That is incredibly specious. It was the guidance of the Policy Manual which I was suggesting needed alteration! And there's nothing stopping you from permitting packages with more than one section.

Never force an installation or update to fail, even if it thinks it’s a bad idea. This includes package conflicts, and overwriting of non-managed files. By all means warn the user and recommend against it, but if they know what they’re doing, don’t stop them! I hate control-freak software in general, but especially where it clashes with RISC OS’s general attitude that an experienced user knows best.

I think this may be harder to achieve as the Package manager probably doesn’t want the system in a bad state, but I’m not sure. The latest PackMan alleviates this a bit by prompting to back up any conflicting files and then retrying the install.

Rick said it better: PackMan needs an 'expert mode'.

Like it or not, this is one of the most important remaining problems with RISC OS packages. Those of you playing Forum Bingo can cross off your "Martin slags off RPMs" square now, because the lack of an override button - no matter whether the package manager thinks it's a bad idea or not - is also one of the most infuriating things about that system. One thing Linux has taught me is that, the more established a package system becomes, the more severely its deficiencies are magnified. I have had so many fake RPM conflicts, often stemming from nothing more significant than the same library being available from more than one repository, that I want to throttle the person who thought "the manager always knows best" was a sensible philosophy.

Remember when I said Linux packages had made maintaining my system an order of magnitude more awkward? Yeah. That. I meant that.

I will not tolerate this malaise invading my home turf.

I’m sure there are edge cases where it can make things more awkward, I just haven’t come across them yet.

These are not "edge cases". There are doubtless some of those, but these are great gaping holes which nigh on everybody who you are hoping to convince of the advantages of package management will stumble into sooner or later - probably before they've even finished setting up, so eclectic is the average RISC OS hard disc, nurtured by two and a half decades of "anarchy".

Interestingly we both have looked at the existing Packaging system and have seen it completely different ways. I think it is well designed and thought out and you seem to believe it is slavishly copied from Linux.

I'm going to tell you something rather harsh, but which needs to be said: What you think doesn't actually matter here. You have set yourself up for the unenviable task of convincing a sufficiently great proportion of the RISC OS userbase to switch to packaging for packaging itself to be viable - which means at least a majority. The incentive for them to spend all this upfront time and effort is practically zero - the onus is on you to convince them, which will never happen for as long as something which will play such a major part in their lives has such large perceived flaws in it. You can't hope they'll look past the aspects of the system they'll dislike, because if there's nothing in it for them, they won't use it, and thus the whole foundation of the packaging project collapses. Not capitulating to demands, however unreasonable they may seem to you, is only ever going to hurt your own cause.

.

Those of you playing Forum Bingo can cross off your “Martin slags off RPMs” square now.

Absolutely priceless can’t get to sleep for laughing.

That is incredibly specious. It was the guidance of the Policy Manual which I was suggesting needed alteration! And there’s nothing stopping you from permitting packages with more than one section.

Alan’s been quite respectful of Graham’s authorship of the Policy Manual, but if Graham isn’t doing any development I think we need to take on its evolution. Which should be a reasoned process, not something governed by programmer expediency (holds up hands, had to make a few decisions I slightly regret under the pressure of deadlines).

Rick said it better: PackMan needs an ‘expert mode’.

Agreed, that would be useful. Unfortunately it’s only Alan and very occasionally me writing it and we’re constrained by time which means progress is slower than we’d like. So we’d welcome input from other people. Not just on coding PackMan but on design, server backend, testing (by which I mean writing code tests), documentation and so on.

I said this on the csaa thread and I’ll repeat it here: package management is all about scale. What works for one or ten packages doesn’t work for a hundred or a thousand (we have about 300 at the moment, Debian has 29000). Likewise managing one machine is easier than managing more, and there are so many more around these days (let’s think, at the moment I manage: desktop x6, laptop x4, server x3, router x3, not to mention dev board x175…). So the system needs to be able to cope with this, with the users of the system not dying of boredom or old age before they’re done.

Let’s study a few selected quotes from a 2010 email conversation with Graham Shaw, shall we?

Comparable situation with GNU/Linux. When it was normal practice to compile from source, people installed more or less wherever they wanted. When you start using a package manager, you just don’t do that.
bq. As on GNU/Linux, package management works just fine when used as intended, but if you try to fight it then it is liable to fight back.
bq. My personal experience is that the urge to tinker soon passes after you’ve had to reinstall a few times.
I fully agree that the nature of RISC OS demands more flexibility than Linux, however there is a difference between flexibility and anarchy.
bq. It may be worth asking whether a package manager is really the right solution to your requirements. An installer would be much simpler, and probably much faster too.
bq. Just like a flesh-and-blood manager, there’s no point employing one unless you are prepared to delegate most of the detailed decision-making and switch your attention to setting high-level strategy. I’m not saying you shouldn’t be able to step in and override it occasionally, but if you’re doing that as a matter of course then it probably isn’t the right tool for you.
These were mostly in the context of trying to persuade him that catering for the possibility of users moving installed applications might be a good idea. This was before I fully appreciated the ramifications of having the manager automatically dump stuff in a fixed location in the first place.

Anyway, to cut a long story short, it didn’t happen. I hope it is now somewhat clearer why, and on what basis, I believe that the design of LibPkg was slavishly copied from Linux without sufficient regard for how that system differs at both a technical and a cultural level from RISC OS.

So to me, it looks like he was trying to put his point across in a reasonable fashion and you didn’t agree with him. He specifically says RISC OS is a more complicated beast than Unix. I think it is perfectly reasonable to use experience on other systems as a guide, you do it yourself in some of your arguments. I can’t see anything in here that leads me to think he wasn’t designing something for RISC OS, just that you don’t agree with one of his decisions.

Well the locations are not random, they’ve been considered by the application authors.
bq. That is exactly the same thing. They’ve been considered… by many very different application authors, each of whom have very different ideas of how things should be done, and different ideas about how RiscPkg works and what it’s for, and different ideas about how the English language works. With minimal central coordination. Have you considered taking up a position herding cats instead? You might find it easier.

Why is it at all like herding cats? I believe developer’s come from a species that can make decisions for themselves and are quite good at pattern matching so they can use common sense to decide where they want to put things.

Also…

Cut down that ridiculous list of categories! And take a leaf out of !Store’s very sensible book and allow packages to be filed under more than one, because really, trying to slice reality into that many discrete non-overlapping black and white chunks is inviting chaos and confusion.
bq. Reasonable suggestions, I haven’t any plans to fix this though, Sections are decided by Package authors using the guidance of the Policy Manual and not really under my control.
bq. That is incredibly specious. It was the guidance of the Policy Manual which I was suggesting needed alteration! And there’s nothing stopping you from permitting packages with more than one section.

Sorry for trying to agree with you. I’m not adverse to either of your suggestions, I just said I wasn’t currently planning to do anything about it.

Never force an installation or update to fail, even if it thinks it’s a bad idea. This includes package conflicts, and overwriting of non-managed files. By all means warn the user and recommend against it, but if they know what they’re doing, don’t stop them! I hate control-freak software in general, but especially where it clashes with RISC OS’s general attitude that an experienced user knows best.
bq. I think this may be harder to achieve as the Package manager probably doesn’t want the system in a bad state, but I’m not sure. bq. The latest PackMan alleviates this a bit by prompting to back up any conflicting files and then retrying the install.
bq. Rick said it better: PackMan needs an ‘expert mode’.

Like it or not, this is one of the most important remaining problems with RISC OS packages. Those of you playing Forum Bingo can cross off your “Martin slags off RPMs” square now, because the lack of an override button – no matter whether the package manager thinks it’s a bad idea or not – is also one of the most infuriating things about that system. One thing Linux has taught me is that, the more established a package system becomes, the more severely its deficiencies are magnified. I have had so many fake RPM conflicts, often stemming from nothing more significant than the same library being available from more than one repository, that I want to throttle the person who thought “the manager always knows best” was a sensible philosophy.

Remember when I said Linux packages had made maintaining my system an order of magnitude more awkward? Yeah. That. I meant that.

PackMan has at least started to allow overrides with it’s prompt to backup the conflicts and retry. I see no obstacle to more control for expert users being added in the future.

I will not tolerate this malaise invading my home turf.

So in one argument you are saying that it’s wrong for someone to decide how something is set out and run and in another you are saying you won’t let people decide for themselves.

I’m sure there are edge cases where it can make things more awkward, I just haven’t come across them yet.
These are not “edge cases”. There are doubtless some of those, but these are great gaping holes which nigh on everybody who you are hoping to convince of the advantages of package management will stumble into sooner or later – probably before they’ve even finished setting up, so eclectic is the average RISC OS hard disc, nurtured by two and a half decades of “anarchy”.

This is true of nearly any application, you always stumble over something sooner or later. If you provide the authors with feedback on why you had a problem it can always be seen if there is a way to make things easier.

Interestingly we both have looked at the existing Packaging system and have seen it completely different ways. I think it is well designed and thought out and you seem to believe it is slavishly copied from Linux.

I’m going to tell you something rather harsh, but which needs to be said: What you think doesn’t actually matter here.

I beginning to think it doesn’t matter what I say to you. I have been attempting to address the points you raise and was hoping that my opinion on Packaging did have some merit, and unlike you I don’t believe I’m always correct.

You have set yourself up for the unenviable task of convincing a sufficiently great proportion of the RISC OS userbase to switch to packaging for packaging itself to be viable – which means at least a majority. The incentive for them to spend all this upfront time and effort is practically zero – the onus is on you to convince them, which will never happen for as long as something which will play such a major part in their lives has such large perceived flaws in it. You can’t hope they’ll look past the aspects of the system they’ll dislike, because if there’s nothing in it for them, they won’t use it, and thus the whole foundation of the packaging project collapses.

I agree, I’d love to be able to persuade RISC OS users to embrace packaging, which was why I try to promote it. But I didn’t come to this wanting to change RISC OS users, I just found a system that I found to be very useful to me and wanted to make it more accessible to others by improving the parts I could see needed improving. Hopefully the actual flaws in it can be addressed and a few more people approach it with a more open mind. It would be nice if you would stick to what the problems actually are rather than using emotive language and trying to frighten people into believing its trying to turn RISC OS into Linux.

Not capitulating to demands, however unreasonable they may seem to you, is only ever going to hurt your own cause.

I won’t capitulate to demands, but that doesn’t mean I don’t take all comments and requests very seriously. And I’m pretty open minded so I can be persuaded to change my opinions, but forgive me if I want to discuss things rather than just blindly do what someone shouts about on newsgroups and forums. I don’t think I know best for all RISC OS users. PackMan has already added the move application feature, improved conflict resolution and other things due to feedback from others.

Regards,
Alan

Even on Linux, package management systems vary. I tend nowadays to prefer Ubuntu and its cousins (because they work better on my hardware) and some of the issues raised don’t affect these (no “vendor change” issues, for example). There is also ‘checkinstall’ which can be used in place of ‘make install’ when compiling from source; it uses the install instructions to create a .deb package and then installs it.

I beginning to think it doesn’t matter what I say to you.

Well, at the risk of upsetting someone, you may well be right. Packages are a thorny issue. For long term and savvy users they are an invasion, for the newbies and less techno-savvy they are a godsend.
For those with better things to do they are just handy and when the package manager has an over-ride then you get the best of all worlds (well most worlds apparently)

I have been attempting to address the points you raise and was hoping that my opinion on Packaging did have some merit, and unlike you I don’t believe I’m always correct.

I think the comments you made had merit. Mind you you can never please everyone and some people have a habit of starting an argument before you arrive so that they are in full flow when you do.

Wow, excellent thread! Entertaining theories about package management….Rushing for the popcorn now!

I would like to see a few features in the package system.

1. The ability to act like store, where it will just download the package (and optionally dependencies) and open the archives so those who need to manually manage their systems, can, but still get the notification and fetching benefits.

2. A dummy package option. (for modules yet to be packaged) to allow programs than need these modules to be packaged before them. (It would check for the module and then give information where to find it, if not already installed)

3. A modification the RMEnsure command, so that failed RMEnsures are passed to the management system, and the second failure would be interrupted with an offer to fetch and install the missing module if the package manager recognized it.

By the way, if you want nested quotes, <notextile> and dropping to vanilla HTML are your friends.

So to me, it looks like he was trying to put his point across in a reasonable fashion and you didn’t agree with him. He specifically says RISC OS is a more complicated beast than Unix. I think it is perfectly reasonable to use experience on other systems as a guide, you do it yourself in some of your arguments. I can’t see anything in here that leads me to think he wasn’t designing something for RISC OS, just that you don’t agree with one of his decisions.

It was specifically this quote which I found most enlightening:

When you start using a package manager, you just don’t do that.

This strongly suggested that he preferred the idea of attempting to mould the users to the system instead of moulding the system to the users. An unrealistic goal for any piece of software, let alone something as fundamental as a package manager.

We’ve banged our heads together many times on this particular point and we’re plainly never going to agree. Over multiple years, threads and online mediums, I’ve been as specific and precise as I think I ever can be on exactly which bits of RiscPkg were lifted from Debian and why some of those bits shouldn’t have been, and all I’ve been rewarded with are blanket flat contradictions alternated with “well it works for me”. This isn’t an argument worth continuing.

Why is it at all like herding cats? I believe developer’s come from a species that can make decisions for themselves and are quite good at pattern matching so they can use common sense to decide where they want to put things.

Ah, the old ‘argument from faith in humanity’ fallacy. As a committed misanthrope, I’ve run up against this particular brick wall in many previous forum arguments. My number one rule for dealing with people (or indeed life in general) is to expect the worst and you’ll never be disappointed, but sadly people will insist on believing that most humans aren’t fundamentally selfish and stupid.

Nevertheless, I will attempt to debunk it anyway.

Here is the complete list of categories defined in the Policy Manual:

• Administration
• Archive
• Audio
• Chat
• Communication
• Database
• Demo
• Desktop
• Development
• Device
• Disc
• Document
• File
• Education
• Emulation
• Font
• Games
• Graphics
• Library
• Mail
• Mathematics
• Miscellaneous
• Network
• Presentation
• Printing
• Spreadsheet
• System
• Text
• Video
• Web

Tell me there’s never going to be any overlap between any of those. Tell me there’s no possible way someone could write an application which applied equally well to, say, the ‘Document’ and ‘Spreadsheet’ categories (oh hello there Fireworkz, available for free now, are we?).

Funnily enough, I see you’ve deployed this exact same line before, in reply to Vince Hudd. Featuring a cameo by my own software. Tell me, did you ever decide whether Cogs was a “toy”, a “game” or a “graphics program”?

The supply of counterexamples to your position that (a) RiscPkg’s list of categories isn’t bloated and (b) there is no room for ambiguity between any of them doesn’t seem to have made much of an impression on you back then either, so I won’t get my hopes up.

That’s one fascinating Usenet thread, actually. Vince made some good points, but I still think David Holden’s post can’t be beaten for succinctness.

PackMan has at least started to allow overrides with it’s prompt to backup the conflicts and retry. I see no obstacle to more control for expert users being added in the future.

Good. This is a step considerably further in the right direction than the implementation of package moving was. It only deals with one source of control-freakery as yet (albeit a very common one, which most users will encounter while setting up packaging for the first time), but I hope more can be added.

Not that I imagine you’re interested, but this is yet another respect in which the design of LibPkg focused rather too heavily on writing a Linux package manager and porting it to RISC OS, rather than starting out with the aim of writing a package manager for RISC OS. Linux, with its sudo and its root and its new-fangled half-decent standards of basic security, to speak nothing of its mainframe heritage, operates on the philosophy that users should be allowed to do as little as possible (see above re. faith in humanity). RISC OS, on the other hand, will happily stand aside and let you do something completely idiotic – which is probably a bad idea if you don’t know what you’re doing, but at least it makes things less frustrating for those of us who do. It’s quite obvious on which side of this debate LibPkg has aligned itself.

So in one argument you are saying that it’s wrong for someone to decide how something is set out and run and in another you are saying you won’t let people decide for themselves.

Smart move. How can I possibly refute your arguments if they don’t even make any sense?

I beginning to think it doesn’t matter what I say to you. I have been attempting to address the points you raise and was hoping that my opinion on Packaging did have some merit, and unlike you I don’t believe I’m always correct.

But it doesn’t matter if I’m correct or not. Obviously I think my opinions are correct, otherwise I wouldn’t have them, but far more pertinent to my point is that I can name at least two people (thus far) who agreed with them sufficiently to write long and eloquent posts explaining their own viewpoints, which broadly align with mine. Every person who does that – plus unknown numbers of other people who read those posts and silently agree – is lost to your cause until the things they dislike have been satisfactorily dealt with.

It would be nice if you would stick to what the problems actually are rather than using emotive language and trying to frighten people into believing its trying to turn RISC OS into Linux.

Oh never mind, you’ve just degenerated into strawmen now.

Drifting off into the realms of whimsy for a moment, I think my ideal package manager would have the user interface of PlingStore and the features of PackMan. PlingStore was originally developed as an answer to what I’m tempted to call the ‘David Holden question’ (you really should check out those links up there), designed on a blank slate with nothing more in mind than how a RISC OS store might work, with no hang-ups about how other systems do it. Unfortunately, unless it’s been considerably improved since I last saw it (I don’t have a copy, so I’m working off hazy memories here), its technical side leaves much to be desired. I don’t think it does either dependency resolution or update checking, which are two of the most important reasons we need a package manager in the first place.

PackMan, on the other hand, has a (fairly) stable, thoroughly tested back-end with lots of handy features, but it just doesn’t look, feel, or work like a RISC OS application, and that same fancy back-end is prone to some rather foreign ideas about how things should work. We need the things it does, it’s just really annoying it does them in such an idiosyncratic manner.

PlingStore is a much neater, slicker, more carefully considered system, but the functionality just isn’t there. PackMan is a shambles in several respects, but is the only system attempting to do the job which actually needs to be done. One represents the extremist viewpoint that RISC OS should be made as much like Linux as possible because Linux is brilliant, and the other represents the equally extremist viewpoint that RISC OS should steer clear of anything forrin-sounding just to be contrary, without giving any consideration to what would be useful to have in practice. I repeat my oft-repeated and progressively more futile-sounding plea: can we not just have the right tool for the right job?

I repeat my oft-repeated and progressively more futile-sounding plea: can we not just have the right tool for the right job?

Sounds fair enough in principle. So let’s do some design.

Let’s assume we’re going to use LibPkg as the framework for doing this since it exists, it’s reasonably modular and well written, there’s a packaging format defined, there’s a server-side backend for making and serving packages, and there’s a back-catalogue of about 300 packages (mostly in a format that can be regenerated should it be necessary with moderate but not painstaking work). In response to David Holden’s point, I ought to point out the LibPkg is written completely from scratch – the only imported parts are zlib and libcurl. (The source is in C++ and reasonably concise, once you’ve got used to the C++isms). If we’re not going to use LibPkg, either point us in the direction of an alternative system on RISC OS that does this, or provide a plan for writing one. Or, alternatively, how you would plug a similar infrastructure into !Store.

Assuming you’re sticking with LibPkg, there’s five overlapping areas to look at:

1. Changes to the policy manual (how packages are organised)
2. Changes to LibPkg (the fundamentals of fetching and installing packages – pushing around the files and the network)
3. Changes to PackMan (the frontend and user interface)
4. Changes to the developer interface to making and maintaining packages
5. Changes to the server infrastructure (how packages are served and advertised on websites)

So please do some design work and tell us how you think it should work, and what you would change. For example, you object to the list of categories. What would you have instead? More categories, fewer categories, multiple categories per package (how many?). How would this work in the Control file and the website listing of packages? These are not necessarily hard questions, but ones that need to be answered.

That’s merely an example, but is the sort of thing you need to refine. That is, not just feel that something doesn’t work, but specify how it should work, including as many corner cases as you can think of. Inkscape has a nice list of suggested improvements with ideas like these 1 2 3 4 which are a good example of how we might go about design. Maybe we could have similar wiki pages to those? All this is not just aimed at Martin – if anyone feels they want things to happen differently, write down exactly what you do want to happen.

Of course, there’s nobody but Alan writing this at the moment, so to make something happen you’re left with: convince Alan to do it, convince somebody else to do it, or do it yourself. But let’s put that aside for the moment and do the design first without worrying about that right now.

Any scheme to categorise artefacts as diverse as software in a form much more complex than “this category is FireWorkz, this one is everything else” is likely to fail.

Why not put everything in a big pile and allow each package to have one or more tags attached? Instead of filtering restricting your view to a specific directory it lists any and all with a matching tag. No permanent decision is made up front to stick it in a special place. New tags can be added fairly simply. Packman already allows a text search of the package descriptions. Just add appropriate category descriptors at the end of the descriptions and have the category filtering tool do a search on that.

Why not put everything in a big pile and allow each package to have one or more tags attached?

That’s basically my multiple-categories suggestion by another name. I got the idea from PlingStore, which already does this. When I saw it, I couldn’t believe RiscPkg hadn’t thought of it.

With regards to Theo’s challenge, believe me, I’d love to. In fact, I believe I threatened to do just that at the conclusion of last year’s epic Usenet discussion, but I never got around to it. You can actually see a couple of my thoughts for how I’d have written the system in my latest post on the Usenet thread steaming on in parallel to this one. I don’t need any encouragement to spontaneously burst into specs!

The main problem is that doing the job properly would require a lot of careful thought, and I’d really rather not commit myself to anything until after my exams finish in May. That said, you couldn’t go far wrong with starting from my list of demands on page 4.

.

Personally I’d like to see a front end that presents itself as a filesystem.

Then you can use google to search and use any other keyword you like

Did you mean . . . <long list of anything BUT what you are looking for> and paid spam links like "Buy Dead Children! on XYZZY. (assuming you looked for something ridiculous like dead children)

better than second guessing what the author thinks is important.

This is why some places allow you to submit additional tags. Maybe we could consider something like that? But certainly the important thing is to use categories as a direction and not an absolute. Is an LED opto-electronic or a semiconductor? Is a sandwich chilled goods or ready meals? Is a cuppa a beverage or a hot drink? Many things do not fit tidy categories.

Hands up if you find program categories on your tv any use.

No. Ditto YouTube; and I wish it would stop suggesting stuff from months ago that I watched once and removed from my list of watched videos. Back when I used the EPG, I never figured out why some news channels were foreign when they gave news in English language, some stuff that did more programming than news was Other and… Eventually I learned channel numbers so I could ignore the preset categories. It might have made sense to Sky (or maybe how they billed) but it didn’t make sense to me, therefore it was wrong…
…for me.
That’s why categories should not be absolute.

By the way, if you want nested quotes, and dropping to vanilla HTML are your friends.

Thanks for that.

We’ve banged our heads together many times on this particular point and we’re plainly never going to agree. Over multiple years, threads and online mediums, I’ve been as specific and precise as I think I ever can be on exactly which bits of RiscPkg were lifted from Debian and why some of those bits shouldn’t have been, and all I’ve been rewarded with are blanket flat contradictions alternated with “well it works for me”. This isn’t an argument worth continuing.

Maybe I’ve just been a little too defensive then. My objection is how you have always been trying to paint the Packaging system as badly designed and directly lifted from Linux with no thoughts to RISC OS. I looked at what it did and how it did it and didn’t think there was anything in it that showed RISC OS hadn’t been considered from the start.

OK, I’m obviously bad at arguing if you think I’ve been making flat contradictions. If something works for me and it appears to work for some other people why shouldn’t I use that as my argument. I’m not saying that I should then just stop there, things should be widened out if it doesn’t work for others.

Ah, the old ‘argument from faith in humanity’ fallacy. As a committed misanthrope, I’ve run up against this particular brick wall in many previous forum arguments. My number one rule for dealing with people (or indeed life in general) is to expect the worst and you’ll never be disappointed, but sadly people will insist on believing that most humans aren’t fundamentally selfish and stupid.

I guess I’m sadly “A glass is half-full” person.

Nevertheless, I will attempt to debunk it anyway.
bq. [snip list]
bq. Tell me there’s never going to be any overlap between any of those. Tell me there’s no possible way someone could write an application which applied equally well to, say, the ‘Document’ and ‘Spreadsheet’ categories (oh hello there Fireworkz, available for free now, are we?).

I can’t tell you there is no overlap, and you probably should be able to use multiple categories. I thought I had agreed it was a good idea already. I just said I wasn’t going to do anything about it now. I believe even the limited system of categories is useful to help browse and find packages, but you’ve rightly pointed out its limitations.

Funnily enough, I see you’ve deployed this exact same line before, in reply to Vince Hudd. Featuring a cameo by my own software. Tell me, did you ever decide whether Cogs was a “toy”, a “game” or a “graphics program”?

A graphics program and I updated the package to reflect that. I listened to the arguments and was quite happy to correct my mistake. My faith in human nature made me think that other people could do the same.

The supply of counterexamples to your position that (a) RiscPkg’s list of categories isn’t bloated and (b) there is no room for ambiguity between any of them doesn’t seem to have made much of an impression on you back then either, so I won’t get my hopes up

OK, once again I seem to have got it completely wrong, I thought I was arguing over the usefulness of categories and not if they were perfect. I definitely agree with you on the overlap problem. I’m not sure if a large number of categories is a bad thing, but maybe they need to be organised better.

That’s one fascinating Usenet thread, actually. Vince made some good points, but I still think David Holden’s post can’t be beaten for succinctness.

Sorry, I can’t remember exactly what was said on that thread, I’m pretty sure Vince did make some good points. I’m not sure about David’s post, as I can’t recall exactly what he said.

PackMan has at least started to allow overrides with it’s prompt to backup the conflicts and retry. I see no obstacle to more control for expert users being added in the future.

Good. This is a step considerably further in the right direction than the implementation of package moving was. It only deals with one source of control-freakery as yet (albeit a very common one, which most users will encounter while setting up packaging for the first time), but I hope more can be added.

Well it’s all about time, design and priorities. Hopefully more can be done in future.

Not that I imagine you’re interested, but this is yet another respect in which the design of LibPkg focused rather too heavily on writing a Linux package manager and porting it to RISC OS, rather than starting out with the aim of writing a package manager for RISC OS. Linux, with its sudo and its root and its new-fangled half-decent standards of basic security, to speak nothing of its mainframe heritage, operates on the philosophy that users should be allowed to do as little as possible (see above re. faith in humanity). RISC OS, on the other hand, will happily stand aside and let you do something completely idiotic – which is probably a bad idea if you don’t know what you’re doing, but at least it makes things less frustrating for those of us who do. It’s quite obvious on which side of this debate LibPkg has aligned itself.

I’m always interested, even when I don’t agree. The Package manager is trying to keep things consistent for you so it can get it the way here. But it’s not doing anything magical to the files, you can run other things along side it and mess about as much as you like with things, but you shouldn’t be surprised if LibPkg then has problems. But it should be able to recover from them.

I beginning to think it doesn’t matter what I say to you. I have been attempting to address the points you raise and was hoping that my opinion on Packaging did have some merit, and unlike you I don’t believe I’m always correct.

But it doesn’t matter if I’m correct or not. Obviously I think my opinions are correct, otherwise I wouldn’t have them, but far more pertinent to my point is that I can name at least two people (thus far) who agreed with them sufficiently to write long and eloquent posts explaining their own viewpoints, which broadly align with mine. Every person who does that – plus unknown numbers of other people who read those posts and silently agree – is lost to your cause until the things they dislike have been satisfactorily dealt with.

Of course they are, and I’ll never be able to satisfy everyone. I’ve tried to argue why the way it works is OK, and why people should try it before dismissing it out of hand. But I do listen to why it isn’t and have been considering what to do about it for a long time.

Drifting off into the realms of whimsy for a moment, I think my ideal package manager would have the user interface of PlingStore and the features of PackMan. PlingStore was originally developed as an answer to what I’m tempted to call the ‘David Holden question’ (you really should check out those links up there), designed on a blank slate with nothing more in mind than how a RISC OS store might work, with no hang-ups about how other systems do it. Unfortunately, unless it’s been considerably improved since I last saw it (I don’t have a copy, so I’m working off hazy memories here), its technical side leaves much to be desired. I don’t think it does either dependency resolution or update checking, which are two of the most important reasons we need a package manager in the first place.

PackMan, on the other hand, has a (fairly) stable, thoroughly tested back-end with lots of handy features, but it just doesn’t look, feel, or work like a RISC OS application, and that same fancy back-end is prone to some rather foreign ideas about how things should work. We need the things it does, it’s just really annoying it does them in such an idiosyncratic manner.

PlingStore is a much neater, slicker, more carefully considered system, but the functionality just isn’t there. PackMan is a shambles in several respects, but is the only system attempting to do the job which actually needs to be done. One represents the extremist viewpoint that RISC OS should be made as much like Linux as possible because Linux is brilliant, and the other represents the equally extremist viewpoint that RISC OS should steer clear of anything forrin-sounding just to be contrary, without giving any consideration to what would be useful to have in practice. I repeat my oft-repeated and progressively more futile-sounding plea: can we not just have the right tool for the right job?

Again this is the problem I have with your arguments, you keep saying PackMan is trying to make RISC OS be as Linux like as possible. It isn’t, it’s trying to provide a good Packaging solution for RISC OS. It’s obviously failing to do this in your eyes, but don’t mistake it’s intent.

I hope we can have the right tool for the right job, I hope PackMan is a least the right tool for some people already and it can be improved to make it better for others.

Regards,
Alan

.

you keep saying PackMan is trying to make RISC OS be as Linux like as possible. It isn’t

The first (only) thing a RISC OS package manager should do when you choose an application for installation is open a save box for the user to drag it to where they want it installed. That is the RISC OS style. If it does anything else then it is not a RISC OS package manager, it is a Linux package manager bodged onto RISC OS and is just getting in the way.

I have to say that putting both !Store and !PackMan on the SD card image for the Pi was a good idea. It puts them in direct comparison. I find !Store by far the easier to use, both for uploading and for downloading.

The first (only) thing a RISC OS package manager should do when you choose an application for installation is open a save box for the user to drag it to where they want it installed. That is the RISC OS style.

In other words you’d prefer a glorified FTP site.

The first (only) thing a RISC OS package manager should do when you choose an application for installation is open a save box for the user to drag it to where they want it installed. That is the RISC OS style. If it does anything else then it is not a RISC OS package manager, it is a Linux package manager bodged onto RISC OS and is just getting in the way.

IMO, it’s not quite as simple as that.

That’s related to what was my biggest concern with RiscPkg and Packman – but it wasn’t my only one, and today I appear to have found a new objection, which I’ll get to later, probably in a different comment.

As I’ve said time and time again, the idea that a packaged app was given a category, and that category dictated its installed location was ignorant of the RISC OS drag and drop paradigm, which is the heart of how we’ve installed almost all applications since the dawn of time RISC OS. (Even apps that came with installers tended to allow the user to drag from the installer to the intended location).

However, the idea of a simple save box for the application that’s just been downloaded by the package manager only really works for a case where the user is downloading and installing one thing at a time. A package manager should allow for multiple downloads and installations – and if that resulted in a stream of save dialogues, it would probably become annoying.

And I can well imagine it causing more problems: The first package has been successfully downloaded, and the [persistent] save dialogue opened. It’s a game, so you open the folder in which you want to put your games and return your attention to the save dialogue in order to drag the icon to the directory. What you don’t notice that while you were navigating to the Games directory, another package had finished downloading and its save dialogue opened. This one’s a graphics application – and its this one you’ve just dragged to [installed in] games, without actually noticing.

No, while the package manager does need to be flexible about where applications are installed, and ought to be making use of drag and drop, just opening a save box when a package is downloaded is almost certainly not the solution.

In the most recent discussion on usenet in which I participated (Martin linked to a couple of posts further upthread), Alan suggested the possibility of providing a facility to move applications via PackMan once installed. I don’t think that would entirely match my ideal solution but, depending on how its implemented, it might be enough to make packaging more palatable to me. (As for my ideal solution: I haven’t given a lot of thought to what that would be, although I do have a couple of loose ideas at the back of my mind – but they should be completely ignored until such a time as I’ve actually used the latest PackMan to remind myself of how it works.)

I know the suggested Move function is now implemented – having mentioned the availability of the update that included this on RISCOSitory – but I haven’t yet tried it to see the mechanism used. (I don’t think I’ve had a RISC OS computer set up on my desk since before the London Show! Actually, scratch that – as I’m typing this I’ve just remembered that I set up the Iyonix a couple of weeks back to rush out a redesign of the Soft Rock Software website. So I could fire it up to try out the latest PackMan. On the other hand, it’s less than two weeks until Wakefield, so maybe that’s not the best use of my time!)

Good grief, using such a small box to comment in is tiresome!

Note: I’ve written this post in a text editor, using copy and paste to get quoted paragraphs, and to get the resulting post back into the reply box. I guess I’ll find out after I hit “save reply” whether that was a good idea.

Maybe I’ve just been a little too defensive then. My objection is how you have always been trying to paint the Packaging system as badly designed and directly lifted from Linux with no thoughts to RISC OS. I looked at what it did and how it did it and didn’t think there was anything in it that showed RISC OS hadn’t been considered from the start.

I think our previous discussion on usenet (in the thread Martin pointed to earlier) might sum this up – if I add a little emphasis to a reply I didn’t make before.

At one point, in response to your comment that “I do believe that package management can make life a lot easier for end users though,” I said:

“I agree – except that for RISC OS, only when it’s written on the basis that it’s a RISC OS package manager.”

You replied with:

“But we have a RISC OS package manager, it just doesn’t work in
the way you want it to.”

What I should have followed that up with is something like:

“No, I think what we have is a RISC OS package manager.”

I’m not sure if that emphasis will help clarify how I see things – but I hope it does.

I guess I’m sadly “A glass is half-full” person.

Your glass is only half-full because it’s been half-emptied. :p

I can’t tell you there is no overlap, and you probably should be able to use multiple categories. I thought I had agreed it was a good idea already. I just said I wasn’t going to do anything about it now. I believe even the limited system of categories is useful to help browse and find packages, but you’ve rightly pointed out its limitations.

And another one is the inconsistencies it presents. I mentioned this in the aforementioned usenet discussion – though I don’t think I gave any examples, and IIRC you didn’t actually respond to this problem. (The example of Martin’s Cogs application was more about how different people would make different choices about what ‘category’ should be used for any given app, which is possibly related, but not quite the same thing.)

I gave much better examples in my post to RISCOSitory about the release of
PackMan 0.7-3 beta – in which I wrote:

This lack of choice is made worse when not only is the category (and therefore location) for any given package not where the user would prefer to install it, and is instead at the whim of whoever created the package – be that the application developer, or a third party – but the categories themselves are inconsistent. Examples of this are easily found on the list of packages on the RISC OS Packaging Project website with, for example, some software being in the “Misc” section (including a package called Manuals, which is an application to store StrongHelp manuals) and some being in the “Miscellaneous” section (including StrongHelp itself), or InfoZip being in the “Archive” section, but Zip and Unzip being in “File”.

That’s bad enough, but in the same paragraph I continued:

There is also inconsistency between different repositories – for example, as noted, the list of packages on the Project website puts StrongHelp in “Miscellaneous” and Manuals in “Misc”, but the list of packages maintained on the RISC OS Open Site (aimed at users of RISC OS on the Raspberry Pi) puts StrongHelp in “Utilities” and Manuals in “Manuals”. Which means that a user with more than one RISC OS computer could wind up with software installed in different locations on each.

I understand that the latter repository was put together in a hurry – by Theo? – and that may be a large part of the reason for the differing categories; the comment isn’t intended to criticise what he’s done, only to highlight the sort of inconsistencies that can happen.

Obviously, it’s possible to address these inconsistencies now with the Move facility you’ve added (indeed, that’s really why I pointed them out in the post, in the run up to mentioning that facility) – but that doesn’t change the point that they are there in the first place, and there will continue to be such inconsistencies with a strict “one package, one category” approach. It’s the possible overlaps that cause this – if an app can be reasonably be categorised in two or more different ways, then different people will have different ideas about which is best: So you end up with similar apps in different places (InfoZip vs Zip and Unzip) and the same app in different places if they’re in more than one repository (StrongHelp in Miscellaneous vs Utilities).

I’m not sure if a large number of categories is a bad thing, but maybe they need to be organised better.

FWIW, I don’t object to the number of categories – and it wouldn’t bother me in the slightest if there were even more. However, the more there are, the more examples there will be of overlaps and inconsistencies. This is why allowing multiple categories is a good idea. (Though it won’t solve the problem of where an app is installed initially, of course!)

Sorry, I can’t remember exactly what was said on that thread, I’m pretty sure Vince did make some good points.

I agree. I reckon I did, too. ;)

I’m not sure about David’s post, as I can’t recall exactly what he said.

Umm. You replied to a post in which Martin linked directly to it.

Oh yeah. Nearly forgot the new issue. I’ve only quickly read the new discussion on csa.apps – and (possibly because previous uses of RiscPkg/PackMan have only been very brief) I wasn’t aware of this before.

Am I right in thinking that as part of the package, the app’s system variables are set up such that, once installed, the variables are defined when the computer is booted, even if the app hasn’t yet been seen? Much like the – user configurable – “Look At” option.

The key words there, of course, are “user configurable”.

If that’s what the package managers are doing, then I consider it a particularly annoying thing to do, unless the behaviour can be turned off (or, like “Look At”, it can be configured by the user for any given package).

I understand that the latter repository was put together in a hurry – by Theo? – and that may be a large part of the reason for the differing categories; the comment isn’t intended to criticise what he’s done, only to highlight the sort of inconsistencies that can happen.

Hmm, given a placement of manuals in “misc” and “manuals” and also stronghelp in “miscellaneous” and “utilities” I’d say that the latter appeared to be at least 50% more correct.
I have difficulty understanding why anyone would prefer to list help and manual files as anything other than either “help” or “manuals” and “misc” or “miscellaneous” just says “I don’t know where to file it” to me. So if we’re on a don’t know where to file it, just pile it all in one big directory and make the user search, or not if you want to be kind to the user…