All 1 entries tagged Management

Next generation package management.

Link to screenshots for the impatient.

It seems to me there are several generations of package management:

• 0th Generation – No package management, user must place individual files in the correct place on his/her system.

• 1st Generation – Software is packaged for easy installation on the target system, user can just extract/run the package and files are placed in the correct place, but there is no dependency checking. If something the programme requires to run is not available it will simply fail to work when run. Examples: old style windows installers, zip files, slackware packages.

• 2nd Generation – Builds on 1st Generation by adding dependency/prerequisite support, so user can know what prerequisites he/she must install in order to use the programme. Examples: MSI, dpkg, rpm.

• 3rd Generation – Builds on 2nd generation by adding automatic dependency resolution from software catalogues/sources/repositories. This means that if all the software & dependencies that the user might wish to install are available in the pre-configured repositories he/she can easily install anything. Examples: apt/smart/urpmi/yast sw management .

We seem to have remained at the same basic concept of 3rd generation package management for quite a while. However, there are a remaining issues that stop it from being as useful as it could be. Problems I see with 3rd generation package management:

• User has to learn how to use a package management frontend. Be it apt-get, synaptic, yast, smart, or whatever. The design of these interfaces vary in ease of use, but even the best designed may still seem foreign to windows users conditioned into double clicking an install file and clicking next repeatedly until done.

• The packages may not be in the standard preconfigured repositories. This can happen both for legal and practical reasons. Some software is not legal to distribute freely everywhere in the world, and no repository can contain all software in any case. In the situation where the software the user wishes to install is not available in the already configured repositories, he or she will have to locate the repository where the software is located, and then learn how to add it as a source to whichever package manager he/she is using. All of which is a lot of effort for someone who just wanted to install something.

So, how can we solve these issues?

Well one solution is to make use of some form of meta-package file which simply contains information about software, and the repositories where it can be located. On top of a 3rd generation package management system this could enable:

• Single click adding of software catalogues, without the user having to worry about where they are located, or how to add them.

• Single click installation of software, whether the repository the software is located in is currently configured in the user’s package manager.

Today I had some spare time so I knocked up a proof of concept for how this could work:

Using an xml file in a format like

With a YaST module to interpret the above, and a default association for the file type in my file manager/web browser I have a working proof of concept for easy package installation.

Here is an example file to install tuxsaver from packman

So the user sees a link to “install tuxsaver” on a website or otherwise obtains the above installation file. And decides he/she wishes to install it. User clicks the link, and the appropriate repository can be added and the appropriate packages installed.

Screenshots of this process.

Alternatively if no packages are specified for installation, the same file handler could act as an easy way to add additional package repositories to the package manager.

Example screenshot of this.

If the module were opened without a file as a parameter it could grab a regularly updated list of available software catalogues from a central location. Obviously repositories hosting packages with dubious legality could not be listed here. However it would enable a project such as packman which is in this situation to host a “Click here to add our project catalogue” link on their homepage, and a “Click here to add mp3 support to your SUSE Linux” etc.

Link to the ycp for this proof of concept.

I think a proper implementation of this concept, included in the distro install by default would have potential to greatly simplify the package management experience for users.

A few issues were raised while I was looking at this which will need addressing:

• de-duping repositories.
  There is no sense in a user having the same package repository added to their package management system twice. My demo will only re-add a repository if the same URL hasn’t already been added, but the same repository may have different URLs on different mirrors. There seems to be no unique repository identifier in rpm-md repositories. One possibility is using the md5sum of one of the metadata files, but this would require making several checks, and ensuring the repository metadata is synced before the process can start.

• Security issues.
  This demo gets for free the security warning from YaST when adding an untrusted repository. It is likely a more clear warning will be required of both the security and technological issues that can be caused by installing random software.

Clearly the format of the meta-package file would need to be thought about carefully. What information does it need to contain, can it be bundled with packages to allow third parties to distribute RPMs which depend on packages in other people’s repositories.

Hopefully this demo might explain the concept better than my previous attempts, and might inspire some real improvements in user experience in future distributions.

: 04 Dec 2006 19:05 |  Tags: Management Opensuse Package Suse |  Comments (7) |  Close comments |  Report a problem