Can RiscPkg/Packman and is it ok to install two applications using a single Package?

Hi,
I haven’t tried this yet, so, if someone here has tried this before and would like to share his/her experience and knowledge on the matter, I would like to install 2 “apps” using a single RiscPkg package.

Why?
Simple, one is the actual app and the other is a !Configure plugin for that app (so I think this has already been considered). It kinda makes no sense to have two packages to install this.

In the worst case, one could try to set that each of the two packages requires the other, but circular dependencies are always a bit of an ugly thing, so I would like to avoid such type of approaches.

Thanks in advance! :)

I think that’s a no-no as they need to live in different places? The user can specify where a normal application is installed.

[Edit: See below…]

I’d perhaps argue the the configuration plugin isn’t Required, but may be Recommended by the main application. Surely the application can run without the plugin ;-)

In the worst case, one could try to set that each of the two packages requires the other

There’s no need for circular dependency, I think. The app can require the configurator, because it can’t run (or can’t run properly) without. The reverse is not true – the configurator can run without the main app, but it’s simply pointless rather than harmful.

No?

I think that’s a no-no as they need to live in different places?

I thought the whole point of the package management was to ensure that application dependencies were installed on the system.¹
If the Configure plugin for an app isn’t a dependency, what is?

¹ If the dependency install isn’t the reason for package management, what the hell is package management for?

I think that’s a no-no as they need to live in different places?

Had the same though, which is why I asked.

The user can specify where a normal application is installed.

That’s a very good point, but according to RISC OS traditional way of working the configuration should reside as a !Configure plugin. I am ok with that and can also add a void in the Icon Menu to call that plugin from the Application itself (this is what many applications do as well). In other words I am trying to follow the directions, but it seems that those are not fully written and/or RiscPkg assumes an app configuration is embedded in the App itself.

Live and learn. All the packages I have installed to date have only ever had one component. The only one I see in the standard repos that has multiple components is Python38, which will allow the user to separately select where each of those components will be installed to. Good luck!

I’d perhaps argue the the configuration plugin isn’t Required, but may be Recommended by the main application.

and

There’s no need for circular dependency, I think. The app can require the configurator, because it can’t run (or can’t run properly) without. The reverse is not true – the configurator can run without the main app, but it’s simply pointless rather than harmful.

Ok, both makes sense to me, so one possible “official” way would be create the App so that:

1) At runtime initialisation checks if a config exists in Choices:MyAppName
2) If it doesn’t it stores there the default configuration
3) If it does exists, just load and use it

The !Configure Applet/plugin (btw what’s the official name for those????) can be installed to handle such configuration and customise the app behaviour from the default one.

How does this sounds? What could be the implications of this choice? (I guess users need to install the plugin/applet to be able to configure the app, hence Stuart point makes sense and set the applet as “recommended”).

I thought the whole point of the package management was to ensure that application dependencies were installed on the system.

On Linux it does work as you describe, but RISC OS is a different beast, so want to make sure I am following what is expected.

If the Configure plugin for an app isn’t a dependency, what is?

A configure plugin is for a user to be able to customise the app behaviour. From a general user point of view is definitely required. However, I am learning how this is defined and perceived on RISC OS.

1) At runtime initialisation checks if a config exists in Choices:MyAppName
2) If it doesn’t it stores there the default configuration
3) If it does exists, just load and use it

That’s exactly how I do it in PipeDream (and Fireworkz) – the first two steps are in the !Run file; if important choices file not in Choices:App then update from default configuration (it uses Copy Newer to avoid overwriting any other bits that may still be there). This caters for crazy users who decide to just copy the application directory over to another system rather than downloading another copy via PackMan (ooh, don’t want to install PackMan everywhere they cry) – it will run without breaking but of course they have left their config behind.

Live and learn. All the packages I have installed to date have only ever had one component. The only one I see in the standard repos that has multiple components is Python38, which will allow the user to separately select where each of those components will be installed to. Good luck!

Scary, but oh well, if this is the precedent, I guess I’ll follow that. Thanks for let me know about Python Packages!

That’s exactly how I do it in PipeDream – the first two steps are in the !Run file.

Cool, thanks! :)

None of the packages here seem to correspond to anything that’d live in a Configure directory, and none of the RiscPkg locations seems to match that. Do you have to plonk it in Boot.RO500Hook.Res.Configure?

None of the packages here seem to correspond to anything that’d live in a Configure directory, and none of the RiscPkg locations seems to match that.

Yup, which is why it’s an odd situation tbh, isn’t RISC OS Style to put configuration plugins in Boot.RO500Hook.Res.Configure?

Do you have to plonk it in Boot.RO500Hook.Res.Configure?

Yes, for pretty much all I am doing with the Desktop Modernisation components.

Right now, I am thinking to add a “!Desktop” Plugin that allows access to the entire desktop customisation set, which would also make more sense from a UX point of view. Why do we have all the specific desktop customisation plugins scattered with the rest of the System customisation plugins?

I mean all modern OS have adopted, in one way or another, some form of organisation of the OS customisation plugins, we still only have that “filer like” window and a bunch of stuff in there. I know time, now it’s free, world ending etc… but all it takes is a subdirectory or some grouping tags to groups plugins in a way that makes it easy to understand “where one is going”.

For instance, there are Configuration plugins that are more for an “advanced user” (CPU Align exceptions etc.) and others that are purely for aesthetic, so definitely domain for everyone.

Anyway just my 0.5c

RiscPkg assumes an app configuration is embedded in the App itself.

In many cases this will be true. The icon bar menu will have a Choices entry, and the Choices window and associated code will be contained within the app.

The plug-ins inside Configure tend to affect the whole system rather than just a single app.

The !Configure Applet/plugin (btw what’s the official name for those????)

The RISC OS User Guide calls them “setup plug-ins”.

You can put the app and the Configure plugin in the same package. It’s just arguable as to whether you should.

Personally I’m of the view that Debian et al go rather overboard in terms of splitting up into sub packages. I think a good test is: can you use one piece without the other? If there’s a plausible use case for that, and there would be a worthwhile space saving from having only one piece, then by all means consider splitting it up. If everyone needs both, or it’s only going to save a trivial amount of space, then combine them.

I don’t remember the structure for Boot components in the package, but IIRC they can be included, and there’s no problem with having both the app and a boot component in the same package.

The RISC OS User Guide calls them “setup plug-ins”.

Thanks Chris, I forgot about the User Guide!

@ Theo

It’s just arguable as to whether you should.

Thx and yes this was part of my question.

The Packages in question are all replace-in for what I personally think are “way too outdated” user-facing features of RISC OS, and so I am replacing them with my own components.

Let me give you some example:

• The App Filer, I have completely redesigned it to what I personally think is more useful, easy to use and fast to find Apps to launch
• The regular Filer, I am completely redesigning it with what I personally think is more advanced and useful
• New components that don’t seems to exists in the Vanilla RISC OS

So, in general for this particular project, all the components I want to package are “system wide” components.

I think a good test is: can you use one piece without the other?

This is a great question. So, I can add logic to the components so that, if there isn’t a configuration in Choices:, they will add their own default one. Hence:

• Can they work without a configuration setup plugin? Yes.
• Can you use them without a setup plugin? Yes.
• Is it practical to have them without their setup plugins? No.
• Do they have a limited set of features without their setup plugins? Yes.

Given that I have reached a 50/50, I thought I’d better to ask for others opinions. I personally think they should be deployed with their setup plugins, because what I want from RISC OS is a cohesive, well designed, functional desktop experience and this IS achievable without modifying the OS. I have described part of the architecture I am implementing in an article on my blog if one wants/needs more details on the matter (but this is off-topic in this particular discussion).

So, if there are no technical objections, I think I would go for embedding both Component and its Configure Setup plug-ins in a single package, but I am open to all suggestions in the attempt to reach the best possible solution (aka compromise) between maintainability and user experience.

Again thanks everyone for all your useful comments, really enjoying this thread :)

If there’s a plausible use case for that, and there would be a worthwhile space saving from having only one piece, then by all means consider splitting it up. If everyone needs both, or it’s only going to save a trivial amount of space, then combine them.

What I think it’s a “plausible” use case are “system wide” or “system components”.

I am not particularly worried about space saving, I am more worried about maintenance, for instance:

1) I update a component with new features
2) New features requires a newer version of configure setup plug-in for the component (if nothing to avoid messing with the configuration file that may need new options present). Sure I could code the component to be more resilient to config files that do not present all required options. But what about outdated values? etc…
3) I want to update safely and consistently both and allow a non-tech-savy user to have the easiest life possible without me having to go crazy for maintaining the entire system set

Without fully considering the specifics of your particular situation, it sounds like it doesn’t make sense to have the plugin without the app, or the app without the plugin, which would suggest they are strongly coupled enough to live together.

I suppose another use case might be if you want some parts to be removed for UX purposes, rather than technical ones. For example, imagine you had separate ‘zip’ and ‘unzip’ apps. It might be that ‘zip’ would simply call ‘unzip’ behind the scenes with some different flags, so there’s no saving in space by only having one. But then if they clutter up the Apps folder someone might want to uninstall ‘zip’ because they never use it but keep ‘unzip’, and arguably that’s a case for making them separate (but have ‘zip’ depend on ‘unzip’, which is still doing all the work)

In general I’m of the view that the packaging should be designed to suit the app, not the app to the packaging. So I wouldn’t be putting in extra code to handle the case where parts aren’t installed, unless there’s a genuine use case where people might not want them to be installed.

add logic to the components so that, if there isn’t a configuration in Choices:, they will add their own default one.

Should do this as a matter of course, to cater for those who move the app without realising that the setup part is elsewhere.

But what about outdated values? etc…

That’s what file version numbers are for. If it identifies as a type 1 file, then these bits have this meaning, if a type 2, then this meaning…

Though, there is a case for not recycling keywords with completely different parameters.

to be more resilient

Assume that there will be that one user that does something stupid like copy in wodges of Lorum Ipsum just to see what happens.

If the software crashes, it’s your fault, not mine. Never depend upon data that is user editable to make sense. Parse it as best you can and don’t be afraid to fault it, but don’t crash.
I trust you’re using the ‘n’ version of the string library calls (snprintf, strncpy, etc) in handling this?

About 5 years back I experimented with implementing Regions alongside Territories. This involved a resource app, !RegionRes, and a configure plug-in, !RegiSetup. These both had locations in !Boot, so I supplied them as a dummy !Boot, to be dragged over the original.

I am not sure that this is the correct way to do things, nor whether it is suitable for packaging, but it does seem quite similar to the arrangement Paolo is working on. I do not think this is an application and dependencies situation.

@ Theo

In general I’m of the view that the packaging should be designed to suit the app, not the app to the packaging. So I wouldn’t be putting in extra code to handle the case where parts aren’t installed, unless there’s a genuine use case where people might not want them to be installed.

Totally agree on your view.

One of the issues I am struggling with, however, is that I cannot seem to be able to find information about how RiscPkg allows migration scripts. I have the fear that it may not and so that would kinda force me to suit the app to the packaging.

Am I making sense?

You’d need to confirm with Alan as I’m not up to date, but I don’t think Packman runs any code from the package as part of the installation. It’s just a fancy unzip tool, it’s not a Windows style installer. So in the way that the user dragging an app out of the zipfile doesn’t run anything, neither does Packman. Of course once installed the OS provides ways to execute things, but not automatically as part of the unpacking process.

I’m not sure how much of this is a design decision and how much is it’s never been implemented, but note that third-party scripts complicate the install quite a bit. In general the installation is arranged so that it can always roll back to a consistent state if something goes wrong mid way (disc full, for example), which arbitrary scripts would make much harder. In addition writing scripts to cope with the variability of people’s setups in a robust way isn’t very easy, and it would be difficult to test them.

But what about outdated values? etc…

That’s what file version numbers are for. If it identifies as a type 1 file, then these bits have this meaning, if a type 2, then this meaning…

Dear Rick, it’s a bit more complicated than that.

In Software Engineering, this type of situation is listed under the category called “User configuration migration process” which includes other possible scenarios. Someone also refers to is as Upgrade vs Update (where an upgrade includes new features that requires new configuration options while an update is considered just as a set of improvements and fixes over the previous model, so no added features that requires a user configuration migration).

This is particularly common in software engineering disciplines like Continuous Integration and Continuous Delivery, or more in general under the umbrella term of Agile Development methodologies. In these disciplines a product is not released when it’s absolutely complete, quite contrary, it’s released during its development phases where only features that have deemed stable enough are made available to the user (everything else is either disabled or not included in the release build).

In these cases many things can change and when a User has customised the configuration he doesn’t want to lose it and so such configuration has to be “migrated” from release to release avoiding the user to have to reconfigure the software at every updates (which most likely would result in a user abandoning the app).

Assume that there will be that one user that does something stupid like copy in wodges of Lorum Ipsum just to see what happens.

If the software crashes, it’s your fault, not mine. Never depend upon data that is user editable to make sense. Parse it as best you can and don’t be afraid to fault it, but don’t crash.
I trust you’re using the ‘n’ version of the string library calls (snprintf, strncpy, etc) in handling this?

I appreciate your desire to bring the discussion at coding level and also your desire to help. But I can assure you that this is not an issue in this case, I have more than 30 years of professional software engineering on my back working in very complex scenarios and environments as well, so definitely handling application crashes of all possible sort and form is something I have been doing for a loooot of time now ;) (beside one can still mess around using the ‘n’ version, JFYI).

However, if it has to be about strncpy, lets get into this for a brief digression:

Best way to handle crashes is to simulate negative tests and adopt proper testing strategies, I have ported two very good Unit Testing frameworks to RISC OS and for C developers, have you had a chance to play with them yet?

Anyway, adding resilience to software actually means more than just strncpy handling buffers correctly and avoiding overflowing or causing application crashes.

Adding resilience means also that the application can handle a situation where it has not enough configuration state to actually know for sure what the user desire. In this case an application relies on a predefined configuration state (what Stuart has mentioned above, by generating the default config and storing it)

In the particular case I have mentioned it also means that the application would be in a mixed state. Part of the configuration has been provided and part doesn’t exists yet (that is because the binary is a newer release that has no configuration migration allowed by the Packaging system). It’s a typical problem in software engineering and nothing unresolved.

So, all I am asking for is to understand what are the already established procedures and means that I need to follow and which are the non established ones.

For example, if RiscPkg doesn’t handle the execution of a migration process at install time, that simply means my binary has to handle that and run such process (either from the application at the first run or from the configuration setup plug-in at the first run after updating).

This for example, is another good reason to package them together. Why? Because, in such case, there is no chance that user may have a system in an “odd state” where the app binary is release 2.0 and the configuration plug-in (for whatever reason) has been left to release 1.x and so would probably result in a messed up configuration.

Am I making more sense? There is obviously more, but I think this post is already very long, so I am happy to discuss further if it’s something we all feel important to discuss on here :)

P.S. I did a quick edit to improve my “traditional bad spelling/messy english”, hope it’s better now, sorry!

@ Theo

You’d need to confirm with Alan as I’m not up to date, but I don’t think Packman runs any code from the package as part of the installation.

Thanks, I’ll try to email Alan. Just to understand what are the features available and the roadmap for when certain things will be implemented (if they will ever be implemented).

I’m not sure how much of this is a design decision and how much is it’s never been implemented, but note that third-party scripts complicate the install quite a bit. In general the installation is arranged so that it can always roll back to a consistent state if something goes wrong mid way (disc full, for example), which arbitrary scripts would make much harder. In addition writing scripts to cope with the variability of people’s setups in a robust way isn’t very easy, and it would be difficult to test them.

I agree that 3rd party scripts can complicate the installation process. Just to be clear I am not arguing on what should or shouldn’t be done by RiscPkg, I am just trying to understand what I can do using it and what I can’t and therefore falls into the responsibilities of my component.

Also I used the term script, but probably, at this level, I should have used the term Migration Process, my bad, sorry for the bad english that led you to think I only meant “scripts”, while a Migration Process could be expressed using different tools, languages, strategies and means.