PackMan - updating with local packages

I have mixed feelings about PackMan, but have been constructively having another look.

One issue I have occurs because I do some autobuilder builds, such GCC and its dependencies. Any build that I do from the latest autobuilder sources may have the same version number as previous builds, as found on PackMan, even if the source has been updated.

As an example having installed Python from PackMan SharedLibs 4.0-Rel5-1 contains SOManager 3.01. However my recent build of SharedLibs_4/0-Rel5-1/zip contains SOManager 3.02. Attempting to update the installed SharedLibs by dragging the new zip to PackMan’s iconbar icon fails with :-

20 Feb 12:34:27 000 00000000: Error from ‡|?: Version 4.0-Rel5-1 or later of package SharedLibs is already installed

How should I get that later SOManager 3.02 installed?

The version number cannot simply be incremented as the the next formally distributed update with up incremented version number could be missed.

I can do something disgusting to SharedLibs_4/0-Rel5-1/zip.RiscPkg.Control such as adding a minor version number changing Version: 4.0-Rel5-1 to Version: 4.0-Rel5-1.1. That works on a drag to PackMan and PackMan then does show that version as current.

Or the new version could be dropped on to the existing !SharedLibs, ignoring PackMan which would be none the wiser.

Is there a right answer to this?

Is there a right answer to this?

Of no great use right now, possibly, but the BootUI test files that Julie Stamp is putting out seem to be headed the right direction for you and other developers in providing a route toward a setup that can be booted from a selection of drives.
In your case you’d be wanting DevBoot and StableBoot

How should I get that later SOManager 3.02 installed?

Normally you would wait until the next formal release (Rel6). You could just side load it in the mean time. It will get updated when Rel6 is released.
You can also increment the AB_ROVERSION so it becomes SharedLibs_4/0-Rel5-2/zip. I’ve never done it this way so don’t know if it definitely works. The GCC stuff is built differently to the normal packages in the autobuilder.

When testing set up a separate autobuilder website. Basically run build-website and point PackMan at the package source file that is hosted on your your local web server. Also use a separate RISC OS machine with a freshly installed PackMan and no other package sources.

You can also set up a Jenkins server to automate most of it.

@ David

I can do something disgusting to SharedLibs_4/0-Rel5-1/zip.RiscPkg.Control such as adding a minor version number changing Version: 4.0-Rel5-1 to Version: 4.0-Rel5-1.1. That works on a drag to PackMan and PackMan then does show that version as current.

Have you tried to just increase the “build id” of the RiscPkg package? the “-x” of the zip file name basically

Every-time I do a build and package, even if it’s same version components, I always increase the build id number of the RiscPkg zip file name.

Not sure if this helps with your specific problem, but this is how I test my RiscPkg installing them on top of the test system (in the early stages I was learning how to package this required even 3 or 4 tests for the same package).

With that said, I totally understand your mixed feelings. I think PackMan needs some improvements, but I still think it’s the way forward.

I did not take this issue any further and reverted to not using PackMan.