uPM - The micro Package Manager

Why uPM?Description of uPM
DownloadsFormat description
uPM commandsFiles and Directories
Packaging Softwareupm.conf Configuration
Bootstrapping a systemInstall from CD
Configuration File ManagementChangeLog
Frequently asked QuestionsPorting to new architectures
Comparison of different package managersBuilding Debian Packages
SYSV under uPM
Things to doHow to contribute


The work here would not have been possible without access to the huge body of software, patches and scripts of the Debian Project. Many of the UPM package descriptions were done based on Debian packaging. I have learned quite a bit about package management during my years (since 1996) as a Debian developer through others in the project. In particular useful was the feedback on Linux software I created (debmake and alien as well as numerous others) and the observation on what other developments resulted from the ideas in those pieces of software. I would also like to thank the Gentoo Project which has recently broken new ground with their source based distribution. I had the opportunity to explore that distribution too when I was a Gentoo developer in the summer of 2002. uPM packaging has also relied on many of the scripts and patches done by that project. UPM was basically created because I saw that the architecture of portage had hit a wall in the same way that I felt the Debian packaging mechanism has come to the limit of what they can do. The uPM package manager itself was written from scratch in C and does not contain any software from the Gentoo or Debian project but it incorporates many insights that I was only able to gain because of the work of those two projects. Debian in particular has always been a source of knowlege, good friends and support throughout the years. It would be great if this would become part of Debian someday.

Christoph Lameter, October 17, 2002

Why UPM?

The number of packages in Open Source Software distributions is growing and growing. The Debian project has 10 thousand packages available today and those packages are maintained by 1000 maintainers. It is to be expected that the number of packages will continue to grow. I think it is realistic to expect that the number of packages will increase to 50-100 THOUSAND when we reach the years 2005/2006.
How can such a huge quantity of software be managed effectively? It would take 5-10 thousand(!) maintainers to do the job with the current approach. The inertia coming with such a big organization is already impacting the availability of newer releases today. A new X and a new GCC seem to require changes that affect many areas. Managing 10000 developers will even be a bigger headache and require processes and policies that will establish strict procedures to manage the project effectively. In turn those tight procedures will stifle the ability to react in a flexible way to new situations.

uPM is an attempt to react to that challenge with a new way of packaging. The technology as always will also impact the way things are done.

  1. Extreme reduction of the amount of information maintained on each package. Ideally procedures should be available that allow an automated retrieval from an upstream site with fully automated incorporation into the distribution. One of the greatest problems with maintaining package using dpkg or rpm is the need to keep the installation scripts current. Installation scripts of multiple packages mostly only do a limited number of tasks in a variety of ways. If changes are needed then all those scripts have to be changed. This is an error prone process and releases are very difficult because there is always something broken in the packages. We need to do a radical change on that front. The amount of scripting for each package needs to be reduced by a factor of 10 to 100. Similar functionality in scripts of multiple packages needs to be centralized.
  2. Separation of package integration issues that are distribution specific from development activities which need to be done by the open source project the source code is obtained from. Debian for example is frequently carrying what amounts to forks of upstream packages (X, Kernel etc). Other distributions encounter the same phenomenon. Often patches are not submitted and not integrated to open source projects. The package manager needs to support patch patch writing that is directly submittable to open source projects. On the other hand distribution specific installation does not need to be done with patches. In my opinion it would be best to form real upstream forks and not use the packaging to provide enhance functionality. Having an upstream fork eases access by others to the improvements made and puts pressure on the original upstream authors to integrate changes. It is the best way to avoid having to maintain a fork over a prolonged time period using packaging tools.
  3. Standardization of build procedures in open source projects. There are already established customs on how software is to be build. Automake is one example of an attempt to formalize the build process. The package manager needs to provide a clean interface so that ideally no patching of sources complying to standardized build procedures is necessary for package integration. Patches that have to be done are to be of a generally nature which will warrant their inclusion in standard sources and allow the package maintainer to use these patches unmodified as obtained from the other sites.
  4. Simplification of package management. Package managers should not work in a mysterious ways but be transparent and simple to operate. The meta data that the package generates needs to be easy to handle and change.
  5. Comprehensive Management of all files on a System. Current Linux system already need tens of thousands of files for a well build out system. It is to be expected that future complex Linux systems will contain hundreds of thousands of files. The package manager must provide facilities to monitor file usage, audit problems and be able to insure the integrity of software installed. The system administrator cannot be expected to know the role of each individual file.
  6. Upgrades must be fully automated. Prompting for user input on an upgrade problem is not very helpful these days since the complexity of Linux systems has increased. The user or administrator will not know what to do about a configuration issue. The package manager must provide intelligent schemes for unattended upgrades and refuse to install a new package if an upgrade cannot be performed without user intervention. If a user decision is forced, as reflected in the implementation of configuration file management in package managers today, then the user will make a decision which might be bad since insufficient knowledge about the issue is available. The current situation is that RPM simply moves the configuration file out of the way hoping for future user intervention. Gentoo does the same and provides a tool that asks lots of questions on how to treat these configuration files. Debian prompts when the config file was changed from the default. All these approaches will not work if a system is being run by a non-Unix person. There are a variety of approaches to work around these issues in the package managers (debconf, taking the management of configuration files out of the hands of the package managers etc). The problem though is an deficiency in package management and needs to be solved in the manager itself.
  7. Flexible Build procedures. It should be possible to automatically build packages from source automatically customizing the build procedure to the needs on a special system and the desired overall configuration of software on the system. Debian has the custom of offering a variety of packages based on a common open source upstream package to address that. But if the build process can be customized then the package variety is unnecessary because custom versions can be build as necessary. This will reduce the number of packages needed. Build procedures need to sense the environment and then do an automated efficient build for the machine. Essential build characteristics need to be tracked by the package management system. Gentoo is allowing the specification of build options but does not effectively track that information which results often in a very fragile system.

uPM - Micro Package Manager

uPM is a package manager that attempts to address these issues by offering an integration of a builder, a classic package manager and an advanced management of package relations (like known from apt).

UPM Sources available

Note that the implementation is not complete nor is it tested too well. I expect the implementation to be complete by version 1.0. Available downloads for UPM: