The Case for a RISC OS Package ManagerBy Graham Shaw. Published: 18th Jan 2004, 19:13:41 | Permalink | Printable
Graham Shaw talks about RiscPkgA package manager is a program for installing, upgrading and removing other programs (and sometimes data too). Other possible features include the ability to:
- download packages over the internet;
- resolve dependencies between packages.
The concept of package management is new to RISC OS, but on GNU/Linux systems it is well established. Examples include apt and dpkg (used by the Debian Project), rpm (the Redhat Package Manager) and Portage (part of Gentoo Linux). Packaging is typically done by the distribution, so (for example) the upstream sources for Mozilla would be written by the Mozilla Project then packaged by Debian, Redhat and Gentoo in slightly different ways.
Traditionally most RISC OS software has been installed by manually copying files. This works well most of the time because files tend to be bundled into application directories, and these can be moved quite easily by drag-and-drop. It falls down as an installation method when:
- there are large numbers of applications to be kept up-to-date;
- there are many files which do not belong to any single application.
RISC OS provides some support for merging files into the !Boot directory, but this is strictly a one-way operation with no way to remove files that are no longer needed. It also detracts from the simplicity of drag-and-drop installation.
A package manager can automate the process of installing shared files, saving effort and reducing the risk of error. For example, if an application needs a particular module in order to run, this requirement can be declared as a dependency when the application is packaged. The package manager then knows to fetch the module if the application is requested and the module is not already installed.
Unfortunately it is neither feasible nor appropriate to simply port a GNU/Linux package manager to RISC OS. The most important difference is that RISC OS does not have a standard filesystem layout in the same way that GNU/Linux has. This means that packages cannot simply specify where each file should be copied to because the destination will depend on the layout of the target filesystem.
RiscPkg handles this issue by structuring packages in terms of 'logical' pathnames. These are converted into 'physical' pathnames by the package manager using a translation table. The table can be customised to suit the target filesystem. It can also make use of system variables to track movable destinations such as the !System directory.
This works well for modules, fonts, and most other types of shared resource. By itself, it is not a good solution for applications because their placement directly affects the end user. Some users put applications in relevant working directories, others keep them away from user data. Any attempt to impose a standard layout would be unacceptable to many ... or at least, it would be unless the effects can be hidden in some way.
The Apps directory on the icon bar provides the start of a solution. When an application is added to the Apps directory its files are not physically copied. Instead, RISC OS creates a small stub application which points to the real copy. This makes it much less important where the real copy is stored, because the user (for most purposes) never has to go there.
Putting every application into the Apps folder is not an option, and in any case this would not achieve the objective of simulating the user's preferred layout. However, the same concept can be used elsewhere in the filing system so that applications appear to be in the places where users want them.
An alternative (but superficially very similar) solution is to use symbolic links of the type produced by LinkFS. A planned upgrade to RiscPkg will provide users with an easy method for creating either links or stubs at their preference.
Some users will still want to control exactly where each real applications is placed. It is possible to do this by adjusting the paths file but I strongly recommend that you don't. It makes little or no difference to day-to-day use of the system, and package management works best when there is a clear distinction between files owned by the package manager and files owned by the user. For users who are adamant that they need this level of control I am looking into ways to partially automate the path changes.
The package files used by RiscPkg are zip files with a specific internal file layout. There are two reasons for this:
- zip files are easy to create using existing tools
- they are easy to unpack without using the package manager
This second point is important because it ensures that packaging is not a one-way process. Not everyone will want to use RiscPkg and I didn't want to lock software away in files they could not access.
There are just two essential parts to a package: the control file and the payload. The purpose of the control file is to provide basic information about the package and its relationship to other packages. This includes:
- the name of the package
- the version number
- labels to classify it by purpose and importance
- the type of licence (free or non-free)
- the identity of the package maintainer
- other packages which must be present for this one to work
The payload must be moved to a subdirectory which corresponds to the logical pathname where it will be placed. There are other files which can be added to a package but none of them are essential. This makes packaging (for your own use at least) a very quick and simple operation.
(Those familiar with the Debian package management system will find many of the internals of RiscPkg very familiar. That does not mean that RiscPkg can do everything that apt and dpkg can - far from it. Some, such as alternatives and pre/post installation scripts, are planned but not yet implemented. Others will be added if and when a need is encountered.)
The design of the package manager goes some way towards defining the differences between GNU/Linux distributions such as Debian, RedHat and Gentoo. More important is the package collection which each distribution provides. Packaging is usually performed by the distribution rather than the upstream developers.
The RISC OS Packaging Project aims to do much the same for our platform. That means more than just making software compatible with the package manager: it must also be compatible with the system as a whole, legally distributable by the project, and of a standard fit for distribution. This is not a licence to make changes at the whim of the package maintainer. It is an opportunity to create a more robust and coherent system than would otherwise be possible.
I am currently preparing a policy manual which will set out the rules which packages are expected to follow (if they are part of the packaging project). This will initially concentrate on the technical requirements of the package manager but need not stop there. Provided a consensus can be reached it can play an important role in setting standards for RISC OS software (or even just enforcing the standards already set by Acorn and its successors).
The current state of play is that the package manager RiscPkg exists with a very basic set of features. There are a handful of packages with which the system can be tested, but initially these are just the package manager and its supporting libraries. The policy manual will be published shortly and once this happens the package collection can begin to expand. There are a number of enhancements planned for RiscPkg (and in particular to its user interface).
The case for using RiscPkg is dependent on both the number of packages available and the extent to which it is able to co-exist with existing methods of working. Both of these will gradually improve with time. The key milestone will be the launch of a 'stable' version of the package collection: that is the point at which the packaging project will be suitable for use by end users rather than those with an interest in development.
Previous: Archiology finds new home
Next: RISC OS 5 online docs updated
DiscussionViewing threaded comments | View comments unthreaded, listed by date | Skip to the end
Please login before posting a comment. Use the form on the right to do so or create a free account.
Search the archives
Today's featured article
Internationalising RISC OS
Unicode, i18n and more explained
30 comments, latest by caliston2 on 16/7/03 8:57PM. Published: 10 Jul 2003
Star Fighter 3000: The Next Generation review
Star Fighter 3000: The Next Generation was born from the 3D0 version of the original SF3K that was ported back to RISC OS and this year freed from programmers' hard discs for the platform to enjoy, writes Andrew Weston. In this review Andrew weighs up much-improved graphics and sound against playability and stability.
19 comments, latest by AW on 9/12/08 8:45PM. Published: 17 Nov 2008
News and media:
RISCOS Ltd •
RISC OS Open •
MW Software •
Advantage Six •
CJE Micros •
Liquid Silicon •
Chris Why's Acorn/RISC OS collection •
The Register •
The Inquirer •
Apple Insider •
BBC News •
Sky News •
Google News •