Blog of Julian Andres Klode

Debian, Ubuntu, Linux in general, and other free software

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.

About these ads

Written by Julian Andres Klode

October 20, 2010 at 17:01

Posted in APT2, General

14 Responses

Subscribe to comments with RSS.

  1. Thanks for the article, simple but interesting :)

    Andrew

    October 20, 2010 at 18:23

  2. Why does it need to be implemented in C ?

    Anders F Björklund

    October 20, 2010 at 20:29

    • 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.

      Julian Andres Klode

      October 20, 2010 at 23:08

      • 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.

        Anders F Björklund

        October 21, 2010 at 09:49

  3. There’s also zypper (type two) on SUSE which is quite fast and very capable.

    marrusl

    October 20, 2010 at 21:08

  4. 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.

    Pla

    October 20, 2010 at 21:47

    • What I do is to merge the common parts into a library, abstract the system-specific parts and put an abstract interface to the system in the library.

      Julian Andres Klode

      October 21, 2010 at 10:47

  5. @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.

    Matt S.

    October 20, 2010 at 22:39

  6. 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.

    Matt

    October 21, 2010 at 08:02

    • PackageKit uses yum, not the other way around.

      Julian Andres Klode

      October 21, 2010 at 10:48

    • 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,…

      bochecha

      October 21, 2010 at 10:49

  7. - generic
    - functional
    - avoid duplicate code

    Choose one.

    Bernhard R. Link

    October 21, 2010 at 10:45

  8. How does one remove “not” in “not progressing very fast”.?

    Tshepang Lekhonkhobe

    October 21, 2010 at 14:16

  9. 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.

    Np237

    October 22, 2010 at 10:43


Comments are closed.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: