The Three Levels of Package Management

In today’s Linux distributions, there are usually two to three levels of package management. In this blog post, I will explain the three levels of package management.

1. Local (dpkg, rpm)

The first level of package management is the ‘local’ level. This level consists of package management tools that install and/or remove packages via package archives such as .deb or .rpm files and a database of the local’s system state.

2. Connected (APT, YUM, Smart)

The second level of package management is the ‘connected’ level. In this level, tools are fetching packages and information about them from (remote) locations known as ‘repositories’ or ‘sources’. A level 2 package manager is usually built on top of a level 1 package manager, for example, APT uses dpkg – but there are also cases where one tool is both, such as opkg.

3. Abstract (PackageKit, Smart)

A level 3 package manager is a tool that supports different level 1 package managers via one generic interface. It may be implemented on top of a level 2 package manager (PackageKit), or may be implemented directly in level 2 (Smart).

Conclusion: Merge Level 2 and 3

Most level 2 package managers share a great deal of tasks, such as solving dependency problems. Merging level 2 package management and level 3 package management would enable us to reduce the number of dependency problem solvers and combine our efforts into a few package managers. Such an implementation would need to be written in C and support all common level 1 package managers in order to be successful. As some might have guessed, this is what I plan to do with the project codenamed APT2, although work is not progressing very fast.

PS: Back from vacation

I spent the more than the complete last week in (mostly rainy) Corfu, Greece and am now getting back to my usual development stuff. I have already processed my news & blogs backlog (1000+ messages) and will now start with my email backlog, so don’t be angry if the answer to your email takes some time.


14 thoughts on “The Three Levels of Package Management

    1. In order to be really usable, the package manager must be a library first. Writing it in C gives us the ability to write bindings for such a library for almost any mainstream programming language.

      1. OK, so the need for C is for inter-operability rather than performance. Good, although takes more work. Even with Vala and lots of GLib, it is much more low-level.

        Smart interfaces with python clients, so needs a Python API anyway. It’s more likely to grow a “Level 1” package manager in Python, than be rewritten in C.

  1. I think the correct solution is to move what 2 and 3 have in common to a shared library.

    Merging levels is almost always a bad choice in the long run.

  2. @Anders

    Well, from what I understand most programming languages are based around C. And the linux kernel itself is written C.

    I imagine it would make for easy implementation into various distros? Correct me if I’m wrong… definitely not the most knowledgeable person.

  3. Isn’t yum implemented by calling packagekit already? My understanding is that yum is now basically the cli for packagekit (at least in Fedora). Seems like what you’re describing.

    1. No.

      Yum is a cli package manager (level 2 in the description bove).

      PackageKit is a library/framework to build cross-distribution package management. It has a cli interface (pkcon) and several graphical interfaces (gnome-packagekit and kpackagekit at least). It can be called through a DBus/GObject API by client applications (e.g Nautilus calls it when you double click on a file and you have no application installed for its mime type, to propose you to search for an application; Gstreamer calls it whe you try to play a movie/music without the correct codec installed,…)

      PackageKit deals with the underlying package manager through backends. It has a yum backend, an apt backend,…

  4. Level 3 was invented by people who had no idea beforehand of how package management works. They came up with nice UI ideas, but what they wrote was nothing more than new frontends – therefore belonging to level 2. It’s just that they didn’t know how to write them correctly, and just introduced another layer that brings more complexity without any added value.

Comments are closed.