Official Release - CMOS

I think Vince’s emphasis is trying to say the same as me! We have a package manager, that does a good job of managing packages, but we don’t have a proper RISC OS way of using it.

Install a package in an arbitrarily chosen location, then go through a whole separate process within the package manager to move it to where you want it? Really?!? That’s not at all convenient or intuitive, as indicated by those still complaining about not being able to move packages!

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).

Coincidentally, I covered this in my latest reply to the Usenet thread as well. (Having a split discussion like this is very annoying!)

This is one of the areas which I’m less familiar with, as it’s more of an implementation detail than inherent to the package format. The Policy Manual states only the following:

A package may claim ownership of a system variable by including a file named after the variable in its SysVars subdirectory.

There are a number of packages distributed which “claim ownership” of Alias$@RunType_XXX, some of which conflict with each other, so I’d hope this was configurable.

There’s also a Sprites subdirectory which IconSprites’s sprite files on bootup. Again, if you really want this, it should be part of ‘Look at’, and strictly optional.

The existence of these two parts of the specification play a major part in my conviction that it was designed for a Linux-like system, and not a RISC OS-like one.

As a user & non developer my view is that the most RISC OS like package manager would consist of a release/installation note & some wetware.

The things RISC OS runs on aren’t mobiles or TVs. No need for plug in & go.

One thing worth remembering for a point of reference.
On my (wife’s) linux desktop there are 2387 packages installed.
On my server there are 373 packages installed (way too many)
How many packages, and how complex are the interdependancies of applications on RISC OS, compared to say gnome, kde etc. and is this likely to increase or decrease and to what degree?
If/when pkgman were to offer OS/firmware updates, would you want anyone to be able to fiddle with the locations etc. ?
If the objectives change, can packman be modified to suit a different (say larger, slightly more complex environment) or is it set in stone?

Malcolm, at the moment there are just shy of 300 packages available via PackMan. Current dependencies are mostly relatively simple, but packaging is a key enabler for ELF shared libraries which have a more complex dependency relationship. Shared libraries are there, they work, they just need a proper rollout which the packaging system facilitates.

PackMan does offer OS and firmware updates at the moment – there’s a Pi RC8 update in the Testing repo (see thread in Announcements). The GUI won’t allow you to move this as it isn’t an !App, but if you fiddle with the Paths file you can make it install them somewhere that isn’t !Boot.Loader. Which, of course, won’t actually have any effect on booting your system and future upgrades will be impotent, but then that’s your problem :)

As I mentioned upthread, the PackMan app is really two components, the GUI and LibPkg which is the backend. LibPkg is essentially a clever unzip tool that understands where to put things and handling things like dependencies. LibPkg should cope just fine with a more complex environment. I’m not sure how well it would handle complex dependency conflicts, but that could be added. PackMan’s GUI is a window into LibPkg, but can be expanded to support such more complex operations.

Categories: yes, this is a bit of a square peg/round hole problem. The repository confusion is that the package lists are merging packages from several sources – they may have consistency within a repository, but things like Misc/Miscellaneous differ between them. I try and tidy these up when merging them, but it’s not always straightforward. By all means get rid of categories and replace with a ‘tag cloud’ if someone’s willing to code this, but things like Misc/Miscellaneous would still happen. Unless anyone has any suggestions to avoid it?

I’m going to duck out of this discussion. Maybe over the weekend if I have time, I’ll start up the latest version of the package manager system and see how I get on.

Oh, and for what it is worth, I’m one of those people with an annoying third option. The glass is neither half empty nor half full, it is in fact an incorrectly sized glass. ;-)

Oh, and for what it is worth, I’m one of those people with an annoying third option. The glass is neither half empty nor half full, it is in fact an incorrectly sized glass. ;-)

Ah. Many years ago at Uni the psychology bods and their lecturer went through that stuff with a group of us – our insistence that a beer glass either had beer in or no beer, but the latter was easy to correct didn’t seem to fit their models.
Half full or half empty was their mantra, limited thinking was our response.

Beer glass? Isn’t that one of those temporary measures for people that can’t attach the direct-to-barrel piping to their oral interface socket?

I’m inclined to agree that a package manager for RISC OS ought to allow installing stuff wherever the user wants it except that we must remember that there are some things that have to go in specific places; like for example the modules I need to have installed for Squeak support. So, I’d posit a post-download dialogue that offers draggable icons for whichever parts may go anywhere (for Squeak that might be the application and a separate icon for the ‘data files’) plus ‘install me’ button(s) for the modules.
There rare also cases where a package needs other packages to be in place – whilst Squeak includes Rik’s HALTimer directly it would be nicer to reference a suitable package so that it can be kept up to date independently of my time and packaging. Similarly for the SharedSoundBuffer and DeepKeys packages.

One extra issue with allowing stick-it-aynwhere is that the package manager would probably need to record where each item went for update purposes; that shouldn’t be hard since the chosen location is known at the time each icon is dragged away and dropped. It might be fun to make it cope with the items being moved later though. How would one keep track of an app that had been installed in $.freds-crap, moved to $.oldApps.freds.whatisthis later?

One extra issue with allowing stick-it-aynwhere is that the package manager would probably need to record where each item went for update purposes; that shouldn’t be hard since the chosen location is known at the time each icon is dragged away and dropped. It might be fun to make it cope with the items being moved later though. How would one keep track of an app that had been installed in $.freds-crap, moved to $.oldApps.freds.whatisthis later?

That shouldn’t be difficult – and I’m reasonably sure I’ve suggested this solution in one of the many previous discussions on usenet about package managers:

1. The user installs v1.14 of !Sausages via the package manager.
2. The user later moves !Sausages using the filer to another location.
3. The package manager notices that v1.15 is available and attempts to update it – but can’t see it where it was installed.
4. The package manager points out to the user there is a problem, and presents a dialogue box into which the user needs to drag the moved !Sausages.
5. Doing so enables the package manager to update its records so that it knows where !Sausages now resides. Just as if it had been used to move it in the first place.

(Step 4 could include an option to deal with this another time).

There will probably be edge cases that people can think of where this wouldn’t work – but for most apps, it needn’t be any more complicated than that.

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.

Yes, it does do that.

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 agree it should be user configurable. I can see the cases where it is useful and I also see why it get’s in the way.

The same for sprites as mentioned by Martin.

For my setup, I’d have the command line apps and Alias$RunTypes booted and nothing else. Ideally I’d like it to be more sophisicated and let you choose which application it uses for any file type from the list it’s installed (and that should include none at all).

This Monday’s ROUGOL meeting will be a demo and discussion about package management.

http://www.rougol.jellybaby.net/

Entry is free, so come along and give your opinions.

Alan – if you are anywhere near London you would of course be very welcome! We don’t bite, well only on the curries :-)

Bryan,

Alan – if you are anywhere near London you would of course be very welcome! We don’t bite, well only on the curries :-)

I’m just a little to far and can’t get there on Monday. I’d love to know details of what’s discussed though.

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.

Yes, it does do that.

I am still struggling with this. Using PackMan 0.7 Beta (21st Sep 2012), I have downloaded Cat (which installs into $.Apps.Cat), MakeDraw (which installs directly into $.Apps), PackIt (which installs into $.Apps.Development) and Countdown (which installs into $.Apps.Games). If I click the ‘Apps’ folder on the icon bar, I don’t see any of these, apart from !MakeDraw. In order to use any of the others I have to open $.Apps and then open a sub directory and then click on the application.

Is this how it is supposed to work? Or should everything be installed directly into $.Apps so that it can be seen?

[!Cat will produce an error at the moment but has been updated from 0.16-1 to 0.16-2 and so should be correct by tomorrow]

I am still struggling with this. Using PackMan 0.7 Beta (21st Sep 2012), I have downloaded Cat (which installs into $.Apps.Cat), MakeDraw (which installs directly into $.Apps), PackIt (which installs into $.Apps.Development) and Countdown (which installs into $.Apps.Games). If I click the ‘Apps’ folder on the icon bar, I don’t see any of these, apart from !MakeDraw. In order to use any of the others I have to open $.Apps and then open a sub directory and then click on the application.

That’s a limitation of “Apps” resource, rather than a problem with the way PackMan works – it does not show ordinary folders and as for apps, it only shows the ROM apps, those found in the Apps folder on disk, or those you have told the system to “Add to apps”.

Therefore, for PackMan/RiscPKG to install an app and have it shown in Apps it must either put it directly in the Apps folder, or it must programmatically perform an “Add to Apps” function. I don’t know if there’s an API for the latter – but either solution would be a nuisance in the long term if you install a lot of Apps.

Not to mention that the point of the categories (problems aside) is to prevent that sort of thing, by having apps located according to their primary function – so having everything appear in Apps would defeat the object.

Perhaps another solution would be for PackMan to create a pseudo-app based on the category name when (a) the user accepts installation in Apps.Category rather than the shiny new drag and drop interface that Alan will implement before Wakefield 2013 >;> and (b) that category is being set up for the first time (or doesn’t have the pseudo-app already). That psuedo-app would go in the Apps folder, and running it would open the correspondingly named category/folder.

That sounded okay in my head, but now I’ve typed it I’m not so sure – the Apps folder would then contain (say) !Games and Games, !Graphics and Graphics, !Desktop and Desktop, and so on. Messy. Perhaps it’s just the beginning of an idea that needs some work, so I’ll carry on and hit “Save Reply” for all to see, rather than delete it and pretend I never thought of it in the first place.

I currently use the ‘feature’ that Resources.Apps does not show sub directories by putting all my downloads and install files in a sub directory of Apps. For example in $.Apps.ArtWorks I put all the different versions of ArtWorks that I have downloaded, along with such things as example files, manuals, odd HTML pages with instructions etc.

Resources:$.Apps is a terrible kludge and ought to have been replaced long ago.

Now if it were an IFS which automatically merged various disparate filing system locations then that would be a different matter. I wrote an FS years ago called LayerFS which could do that kind of thing.

But a bunch of stub files sitting in the RMA so they can be linked into what is otherwise ROMFS is wasteful, restrictive, counter-intuitive and stupid.

But a bunch of stub files sitting in the RMA so they can be linked into what is otherwise ROMFS is wasteful, restrictive, counter-intuitive and stupid.

Yes.

I have updated my app !Cat in PackMan to download the app itself into a subdirectory of $.Apps and to download a shell application ‘!Bodge’ which anticipates that a directory called ‘Bodge’ will contain one or more obey files. It contains a single obey file to add the app in its subdirectory to Resources:$.Apps using the ‘AddApp’ command. That takes it to version 0.16-3.

At the penalty of a single added application ‘!Bodge’ in Apps, which anyone adding something to a sub-directory of Apps can use and include their own obey file in the directory ‘Bodge’ inside $.Apps.!Bodge then the added applications will now be visible in the ‘Resources:$.Apps’ folder.

Expedient rather than elegant, I’m afraid…

No doubt a better solution [to the problem that apps installed into a sub-directory of $.Apps can only be executed if you know where they are on the disc and look for and find them; sub-directories are not listed in Resources:$.Apps] will appear in due course.

My understanding of the philosophy as to whether a particular application should reside in $.Apps or $.Utilities or !Boot.Resources is as follows:

if the app does not do anything visible when it is executed then $.!Boot.Resources

if the app is one that is only likely to be executed to edit (rather than create) a file [i.e. in response to a double-click on a particular file type] – for example to edit a JPEG – then $.Utilities

if the app is likely to be executed to create a file – e.g. a text file – then $.Apps.

then the added applications will now be visible in the ‘Resources:$.Apps’ folder.

Well – it works but I’m not looking for an award: kludgy and inelegant.

PackMan 0.7 Beta (21st Sep 2012) produces a few errors but it all works if you just ignore them.

PackMan produces an error “Repeat: ‘SDFS::RISCOSPi.$.Apps.!Bodge.Bodge.~RiscPkg++’ is a directory” and “File ‘<Obey$Dir>.!Sprites’ not found”. It complains [if you upgrade rather than download for the first time] that it overlaps with another package – Cat and Countdown both use !Bodge – but again it all works if you just ignore the errors. It also seems to overlook the dependency that !Cat requires !MakeDraw, despite it being in the Control file [I have revised Cat to 0.16-4 to try to overcome this and will test tomorrow].

Chris,

PackMan 0.7 Beta (21st Sep 2012) produces a few errors but it all works if you just ignore them.

PackMan produces an error “Repeat: ‘SDFS::RISCOSPi.$.Apps.!Bodge.Bodge.~RiscPkg++’ is a directory” and “File ‘<Obey$Dir>.!Sprites’ not found”. It complains [if you upgrade rather than download for the first time] that it overlaps with another package – Cat and Countdown both use !Bodge – but again it all works if you just ignore the errors. It also seems to overlook the dependency that !Cat requires !MakeDraw, despite it being in the Control file [I have revised Cat to 0.16-4 to try to overcome this and will test tomorrow].

I’m a little unsure of why you need this bodge rather than letting the users use add to apps from configure, but as you do then the best thing would be to create a separate package for your !Bodge application and make that a dependency of !Cat and !Countdown. You then add the files into your Bodge subdirectory in the Cat and Countdown packages. i.e. as well as !Cat you add a skeleton !Bodge package that only includes the Apps.!Bodge.Bodge.!Cat file.

Looking at the !Cat package I think it’s missing the Depends line because it needs " ." (space dot) to indicate a blank line in your description.

Please feel free to email me (address in !PackMan and !PackIt help) if there is anything I can do to help further.

My understanding of the philosophy as to whether a particular application should reside in $.Apps or $.Utilities or !Boot.Resources is…

Mine is pragmatic:

• Does it need to be running already? Yes: Boot
• Does the user double click it? No: Resources
• Is it a sportscar? Yes: Apps
• Is it a spanner? Yes: Utilities
• Anything else: Please yourself

Many thanks for your help.

I’m a little unsure of why you need this bodge rather than letting the users use add to apps from configure

The whole point of PackMan is that such things should be done for you. Otherwise you use something like !Store where you do everything yourself.

then the best thing would be to create a separate package for your !Bodge application

I did think of adding !Bodge separately and making it a dependency (but only afterwards)!

Looking at the !Cat package I think it’s missing the Depends line because it needs " ." (space dot) to indicate a blank line in your description.

A consequence of editing the zip file manually, I suspect. Not appreciated the ‘space dot’ issue.

As both progs are dependent on !MakeDraw, I have now hidden the bodge there. Others will have to do their own thing now.

This now (09:30 24th April) works with no errors with Cat 0.16-4, CountDown 0.09-3 and MakeDraw 2.51-1.

Re: Add to Apps

The whole point of PackMan is that such things should be done for you. Otherwise you use something like !Store where you do everything yourself.

I’m currently looking at a redesign of the install screen to allow install locations to be set for packages. As part of this I’m looking into adding other configuration options to the “Draggable” applications of the package. At the moment I was just thinking of the LookAt at boot time.

Do you think it would make sense to add a checkbox at the same time to provide the Add to Apps option? If this was added would it mean you no longer needed your bodge?

I haven’t finished my investigation into if it would be a good idea to replace the current SysVars/Sprites things with using the standard LookAt option, but Add To App could be considered independently of this.

Do you think it would make sense to add a checkbox at the same time to provide the Add to Apps option? If this was added would it mean you no longer needed your bodge?

I think that would be a good way to solve this one. The bodge is fairly hidden now for my apps anyway.

The whole point of PackMan is that such things should be done for you. Otherwise you use something like !Store where you do everything yourself.

But what about people who don’t want Cat in their Apps folder? Unless I’ve misunderstood what you’re trying to do, it seems that you are taking that choice away from them.

This gets back to the point that a lot of people have been making: PackMan is a great idea but needs to allow people more flexibility over installation.