Moving instead of stubbing? Maybe it’s time to stop snubbing!
The end of November saw the release of a new version of PackMan, an alternative package manager to RiscPkg for downloading and installing software for RISC OS computer systems that has been packaged and distributed using the RISC OS Packaging Project.
Packaging on RISC OS has been a contentious issue since it was first introduced, with valid arguments for its use being presented by its proponents, and equally valid arguments, frequently about the implementation above all else, being presented by its opponents.
The idea behind packaging is a very sound one: To make it as simple as possible to find, install and update software. The package manager is configured to check one or more package repositories, from where it fetches a file detailing what software is available. The software is categorised according to the type of function it performs and, obviously, the version number is included so that the package manager can compare it with the version already installed (if any) and update it if necessary. This information, and more, is presented to users so that they can decide what software they want to install on their computers in the first place.
One of the biggest arguments against this system is that it removes the user’s choice because, when it is used to install software, it does so by using the category given for the package to determine the name of the directory in which it should be installed – something categorised under “Graphics” would be put in a directory called “Graphics”, something categorised under “Games” would be installed in a directory called “Games”, and so on. This has frequently been criticised – including by yours truly – as being non-RISC OS-like. One of the strengths of RISC OS is its extensive use of drag and drop, and that has been the mechanism by which applications have been installed since the outset in most cases – with that providing the user with a choice as to where things are installed (with exceptions, of course – certain things do need to be installed in certain places; system resources, for example).
This lack of choice is made worse when not only is the category (and therefore location) for any given package not where the user would prefer to install it, and is instead at the whim of whoever created the package – be that the application developer, or a third party – but the categories themselves are inconsistent. Examples of this are easily found on the list of packages on the RISC OS Packaging Project website with, for example, some software being in the “Misc” section (including a package called Manuals, which is an application to store StrongHelp manuals) and some being in the “Miscellaneous” section (including StrongHelp itself), or InfoZip being in the “Archive” section, but Zip and Unzip being in “File”. There is also inconsistency between different repositories – for example, as noted, the list of packages on the Project website puts StrongHelp in “Miscellaneous” and Manuals in “Misc”, but the list of packages maintained on the RISC OS Open Site (aimed at users of RISC OS on the Raspberry Pi) puts StrongHelp in “Utilities” and Manuals in “Manuals”. Which means that a user with more than one RISC OS computer could wind up with software installed in different locations on each.
The simple solution to such issues would be to use a package manager to find, download and install applications, and then for the user to move them to more suitable locations once they are installed. However, the problem then is that once moved, the package manager can no longer update the software if new versions are released – very much defeating the object. An alternative would be to copy the installed software to new locations, rather than move it, but then the user has to copy updates as well – again defeating the object somewhat, as well as possibly not working in all cases, depending on the way any given user’s copy options are set up.
The better of the RISC OS package managers, PackMan has already provided a way around this problem for some time, through the use of “stub applications” – a drag and drop from the Application Window to a filer location would create such a stub application, which could be used to launch the real thing, still installed according to the package’s category. This was not a perfect solution, however, since App_1 – which the user might want in Dir_xyz – might have been installed in Dir_abc, along with App_2 – which the user might prefer in Dir_abc. By following the stub application solution, the user will end up with an apparent App_1 and App_2 in both of those directories.
Confused? You could be if you actually adopt this “solution” for too many applications!
The latest version of PackMan – version 0.7-3 beta, released at the end of November last year – attempts to address the issue in a much better way, by allowing applications to be moved from their default install location. If, after installation, a package is moved using PackMan, the manager will remember its location so that it can be used to update (or remove) the software in future. Where the destination of a move already contains an application of the same name, PackMan will confirm with the user that it is to be replaced, and will then create a backup of that application. The backup function is also used when creating stub applications – which developer Alan Buckley describes as “the recommended way of being able to access packages from other locations,” but your mileage may vary; mine certainly does – so that such a stub application won’t overwrite a real one.
Another issue with package management software has been where a user attempts to install something, but a previous version is found that wasn’t installed (and therefore isn’t managed) by the package manager – a problem that often cropped up when certain resources were being installed as dependencies (where one package says it needs another package, so the second package has to be installed as well). In these circumstances, the package manager complained, and the user was expected to manually remove the existing file(s). The new version of PackMan also includes facilities to deal with this issue, by presenting a Conflict Manager window, which gives the user the option of letting PackMan backup the conflicting files.
A new Backup Manager window has also been added, allowing users to keep track of the backups it creates, from which the user can view, delete or restore backups.
If you already have an earlier version of PackMan or RiscPkg installed, you can – unsurprisingly – use either of these programs to install or upgrade PackMan to the latest version. If not, you can download and install the latest version manually, and thereafter use it to upgrade to newer versions if and when they appear.
