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

@ Steve

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.

Thanks, the more feedback I get the more I am prone to think I need to package both in the same package.

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.

One might give it fancy titles, but isn’t this pretty much how it’s been for a long time?
Ever since internet access became commonplace, it was normal to release a product that was deemed “good enough” and to provide updates and patches afterwards. Windows, the infamous Patch Tuesdays, Linux and it’s various kernel updates. Even Android and iOS get in on the game (though to a lesser degree as updating flash is a little more complicated, and in the case of Android a lot of manufacturers just don’t bother).

he doesn’t want to lose it and so such configuration has to be “migrated” from release to release

Yes, which ideally means a file format identifier in order to understand how to interpret the data within.
A real life example. I saved the configuration of my Livebox 2 and used it to configure the Livebox 3. It did most of the setup, but missed a few things (things that the Livebox 2 didn’t actually have, like IPv6, in which case it used defaults). I then saved the configuration from the Livebox 3. The file (which in both cases was compressed gibberish) was a bit larger.
So the Livebox 3 understood not only it’s native settings, but the older format too. It might even have understood the original Livebox setup, but I didn’t have a file to test.
[this was mostly in order to have all the NAT reservations and the No-IP and ADSL passwords transferred over]

where it has not enough configuration state to actually know for sure what the user desire.

Nothing new here…begin by applying the sensible default settings. Then overwrite with the user’s configuration. That which is not specifically defined gets the default.
You can’t second guess the user or presume to know what they want. You can only provide useful defaults and wait until the user says otherwise.

A little example of not being useful – the HCCS IDE mini podule for the A3000. It had a ROM onboard with IDEFS, and one could set up various options. One of these options was how long, at boot, to wait for the harddisc to respond. Now, the problem was that if the CMOS memory was cleared (or the hardware installed on a new machine), the default value would be zero. IDEFS would duly take that to mean “wait for 0 seconds” and would consequently fail to see the drive (it wasn’t fast, about 8 seconds to spin up and respond).
It would have been, literally, two instructions to make this work in a user friendly way. Is this byte zero? If yes, assume ten seconds.
Then the drive would respond and be seen by the system.

Best way to handle crashes is to simulate negative tests

Of course. That, and plenty of sanity checking along the way. As you say, there’s a lot to “resilience”.
Especially, knowing that longjmp is not your friend, it’s your final final resort.

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.

File type identifiers, and the ability to handle both types of file, would make this less of a problem. Obviously it’ll be incomplete, which is where you can warn the user upon loading the older file.

As a rule, if the format of a file changes, my software is able to load old and new (even if it only writes the new format). There have been some changes along the way with Manga’s various files.

This for example, is another good reason to package them together.

If they’re interdependent, then yes, it would make sense.

Paolo,

I don’t look at this forum as much as I used to so I’ve only just seen your posting.

To answer your questions (or I think what your questions were).

A package can install to multiple directories and can have any combination of fixed and user settable install locations.

There is a system of triggers that can be added to a package to run extra processing during the install, update or removal of a package.

Config is a little awkward because PackMan will replace files on an upgrade, so if you have user editable files included in the config that’s not so good.
Possible workarounds are:

• You can use the trigger system above to get around this, but it isn’t straight forward.
• If your config will never be updated you could put it in a separate package and never issue a new version (unlikely to be useful).
• You could have a skeleton config shipped that contains just the files that are not going to be modified by the user (e.g. if it’s an app you could have the sprites etc and layout in it).
• I’ve usually had the application have the defaults and write user settings to choices when necessary. I guess that doesn’t help if you need the config plugin.

Let me know if I missed any points, you can always contact me via the email in the PackMan help and I try to respond to forum posts within a few days of seeing them.

PackMan development is fairly slow, but if there is something useful that could be done to help support config/choices in a package I’m always glad to discuss ideas. (Most PackMan development has been driven by discussion with individual users or on forums).

@ Alan,
you are absolutely amazing sir! :)

That is EXACTLY what I was hoping to have! :))))))

You can use the trigger system above to get around this, but it isn’t straight forward.

This seems the option I am seeking for, basically use a script to CREATE (instead of copying) a configuration. But if it’s complicated I can add a piece of code (even a simply BBC BASIC that gets executed at both running the Setup Plugin or the App if the configuration file does not exists.

This way I have only one place where I deal with the config file generation or migration in case of upgrades (better architecture and easier to maintain). Such program will obviously be installed via Packman as part of the App and so updated when an update is installed.

I only want to have one place where I handle this and then have an easy way to trigger that creation and/or migration program easily. If I can do this in a RiscPkg it’s like a “set and forget”, in the App and configure set-up plugin it can be the same.

PackMan development is fairly slow, but if there is something useful that could be done to help support config/choices in a package I’m always glad to discuss ideas. (Most PackMan development has been driven by discussion with individual users or on forums).

Thanks a lot for this, and thanks for the info, for a moment I thought Packman was only unzipping, but instead it’s truly a nice piece of software Alan! :)

I may need some help experimenting with the “triggers” if that’s ok.