Adding packages to the package repository

What is the current procedure to get software added to the ROOL package repository? I should like to get a range of my software added. I could just put the packages up on my own site, but that then requires yet another url adding to the package sources.

Good question!

I guess I ought to check and package some of my stuff; but I’m wondering if any of the things I’ve written are general-purpose-useful enough to be added? Suggestions/requests welcome.

See the bottom of:
https://www.riscosopen.org/wiki/documentation/show/RISC%20OS%20Packaging%20Guide

On a related point I note that the packman doc sayeth-

PackMan does not support installing things into Choices. This is deliberate, because user settings live there – PackMan leaves Choices completely alone when upgrading software – if it didn’t, it would overwrite your choices with the defaults of the new version. In addition, some versions of RISC OS support multi-user mode, where each user can have their own Choices.

Given that Squeak needs DeepKeys, which is recommended to live in Choices.Boot.Predesk, how would one arrange for its installation?

Given that Squeak needs DeepKeys, which is recommended to live in Choices.Boot.Predesk, how would one arrange for its installation?

Supply “DeepKeys” as a dependency to your program. The “DeepKeys” archive (separate) is an application that installs itself to somewhere ($.Utilities ?) and when run it loads the module and copies it into Choices:Boot if necessary.
It is hacky. Yes. Ideally, the next iteration of PackMan would allow Choices:Boot¹ to be an exception to the rule (or else how does one expect to install/upgrade resources intended to start at boot time?).

¹ BTW, I’m not thinking nor concerned about user profile support at this point. It would be ludicrous for us to cripple our packaging support to not allow boot-time installations because of a feature of an alternative iteration of RISC OS that is the product of another company entirely. If ROLtd or any RO4/Select/Adjust users disagree, RiskPkg source is available, ROLtd can add in support for their specific multiuser Boot whenever they want…

Thanks Theo. Need to get organised then.

It is hacky. Yes. Ideally, the next iteration of PackMan would allow Choices:Boot1 to be an exception to the rule (or else how does one expect to install/upgrade resources intended to start at boot time?).

Graham’s most recent RISC OS Packaging Project Policy Manual mentions BootToBeLoaded and BootToBeTasks as top-level directories in the package file to be mapped onto Choices:Boot.PreDesk and Choices:Boot.Tasks respectively. However, we’ve been a bit unsure about these and haven’t implemented them in the current Paths file that comes with PackMan (your installed copy lives in $.!Boot.Resources. !Packages.Paths).

I’m not quite sure of the best way forward on this. Yes, we need to support running things on boot. But whether it’s better to put the actual code in Choices:Boot or keep the code elsewhere and put scripts to execute it in Choices, I’m not sure. On the one hand, putting executables in Choices feels awkward. On the other, there’s a limited amount of the system which is up by the stage of PreDesk, and I’m not sure how many system variables will be set up by this point.

On the multiuser point, it’s not just limited to the ROL branch. For example, network setups can have separate system choices and user choices. Whether any actually do, I’m not sure. But I’d be reluctant to break the choices system which has been carefully designed to be flexible.

Tim asked

Given that Squeak needs DeepKeys, which is recommended to live in Choices.Boot.Predesk

It’s not merely ‘recommended’, that’s its officially allocated home.

Rick suggested:

Supply “DeepKeys” as a dependency to your program. The “DeepKeys” archive (separate) is an application that installs itself to somewhere ($.Utilities ?) and when run it loads the module and copies it into Choices:Boot if necessary.

The horror, the horror. No, let’s not do that.

Theo responded:

However, we’ve been a bit unsure about these and haven’t implemented them in the current Paths file that comes with PackMan

The problem is that we don’t want people installing stuff in there without an allocation… but stuff that has been allocated should go where it is supposed to go, without using a packager to install an installer that installs stuff. That’s madness.

Tim, I’d make Squeak the installer – if DeepKeys isn’t present and isn’t already in ToBeLoaded, copy it in there as well as RMEnsuring it.

Loading DeepKeys on demand is not a good idea because it will clobber any existing claimants of InsV etc. This is unavoidable without VectorExtend (and I haven’t made an RO5 version of that yet, sorry) so it must be loaded as early as possible. And that’s why its officially allocated name is “!!DeepKeys”. Now that’s hacky. :-/

Given that Squeak needs DeepKeys, which is recommended to live in Choices.Boot.Predesk, how would one arrange for its installation?

I was trying last year to create a DeepKeys package when I came across the problem with it needing to be put into BootToBeLoaded. In the end I got permission from Graham to change the LibPkg back end used by PackMan to add the two new install locations BootToBeLoaded and BootToBeTasks. My solution to the multi-user problem is that these virtual directories are mapped if they haven’t already been defined on startup to the all users version of these.

This means that as soon as I get the next release of PackMan out, I should be able to Package DeepKey using the BootToBeLoaded folder.

I’m hoping to soon get the next PackMan version to the ROOL testing package list so it can be tried by a few more people than myself before it goes on general release.

Tim, I’d make Squeak the installer – if DeepKeys isn’t present and isn’t already in ToBeLoaded, copy it in there as well as RMEnsuring it.

Hmmm, nice random applications¹ installing things in various places in the boot because where the application developer specified a copy it doesn’t exist.

Isn’t that a package handler job, not the application? Re-inventing the wheel or what?

¹ Maybe it’s sort of OK in this instance, but not a good trend really. Where applications sit may be user preference, where the supporting modules sit is always going to be a specific portion of boot – unless people start specifying different things in their application installer…

Alan said:

I was trying last year to create a DeepKeys package

Thanks for that. As the author and maintainer it ought to be my responsibility but I’ve not looked at the package stuff. Mea culpa.

Steve observed:

random applications installing things in various places in the boot because where the application developer specified a copy it doesn’t exist.

Well hang on, it’s not actually anarchy.

We’ve long had the idiom of an application including soft-load modules that it requires in case the host OS is missing them – ColourTrans, even FontManager (yes, I’m going back a bit now!). That was a much worse situation since the version that got loaded rather depended on the age of the applications you had and their run order.

In the case of such a module that has a known installation point, I think auto-installation is probably better than RMEnsure/RMLoad. That isn’t to say there couldn’t be a confirmation step. My Cerilica MMK keyboard had such a complicated set of support modules I had to write a modular installer, but that was a keyboard driver – having a GUI program to install another GUI program is silly IMHO.

The ideal would be an RMUpdate command, eg:

RMEnsure DeepKeys 2.06 RMUpdate <Boot$ToBeLoaded>.!!DeepKeys 2.06 <Obey$Dir>.!!DeepKeys
RMEnsure DeepKeys 2.06 Error "You will have to reboot your machine to run this program"

Off topic: The above Obey snippet makes me wish that <Obey$Dir> was in the run path during Obey execution… that way an app could include its own ‘RMUpdate’ utility which would get used if the OS didn’t have one already. Ho hum.