The APT2 project

I just started working on a replacement for APT written in Vala and called APT2 (I know, the name could be better). The main idea behind the project is to create a library for working with Debian repositories and packages, and on top of this library a few applications. This is different from APT because the project focuses on the library part, whereas APT is primarily focused on the application part.

I chose Vala for this task because it has an easy syntax and allows me to use the features provided by GLib and Co. really easily. GLib provides many functions needed for APT like file access, unicode handling, hashsums creation. It also provides us with signals which are useful for implementing progress reporting.

Another project, called ‘cupt’ tries to provide an APT replacement in Perl. Apart from the fact that I don’t like Perl, it also has the disadvantage of being too big to ship on embedded devices and is not useable from other languages such as Python or C/C++. Yet another project, ‘smart’ provides a different package manager written in Python. While I like Python, it can’t be used from languages such as Perl or C/C++ and is too large. APT2 will only require GLib, Gee and libarchive, which require about 2MB of space; about 1/10 of Perl’s size.

The core of APT2 is a library called ‘libapt’. At the moment, this library provides classes for reading tag files (TagFile&TagSection) and an incomplete configuration class based on libgee’s HashMap (to ease coding, it will probably be changed to a special data structure like those in apt-pkg). The next step will be implementing a parser for configuration files (currently we only support in-memory objects) and writing the Acquire system.

The planned Acquire system uses GModule to modularize the support for different URI schemes. Each module provides a worker class which implements one or more URI schemes. The first of these modules will provide a worker using GIO, which deals with local file access, samba shares, FTP, SFTP, WebDAV and various other protocols, including HTTP until a replacement has been written (since we don’t want to force gvfs-backends). The workers communicate with the parent Acquire object using signals and can cause the whole acquisition to be aborted by emiting an “abort” signal (or similar).

The whole project has just been started and may take some months until it becomes useful (if it becomes useful at all). The code can be found at and is licensed under the MIT license (see It is a secondary project and will not affect my work on apt (not much yet) and python-apt (0.8 series).

28 thoughts on “The APT2 project

  1. And what do you think about Parrot project for develop APT2? I think that is a very good virtual machine that supports python, perl, etc…

    It will a good idea if Parrot can compile in native code.

    PS Sorry for my english.

  2. My memory of initial apt development is that it was very library focused, and indeed the only frontend development done for a long time was this minimal “apt-get” demo.

    1. The goal of libapt in APT2 is to create a library that behaves as one would expect from a GObject based library, it uses exceptions and other stuff. apt-pkg and apt-inst in contrast use some kind of a stack to which errors are pushed and popped. This approach is good for user interfaces, but is not a good idea if you need to know the exact cause of the problem.

  3. Why not open the project up to include RPM based distros, as well? I’m sure there are a lot of RPM community distros that would love to use such an app, as Apt4RPM has been pretty much abandoned. Think about it this way, we could really use a unified package management system accross distros and nothing that has attempted to come to the forefront has been able to put a dent in the idea. Adoption by both Debian users and RPM users would go a long way.

  4. One of the nice things about dpkg is the lack of dependencies it seems to have. When the system is broken, I can typically repair dpkg fairly easily.

    Apt, otoh, requires a working libstdc++. Due to C++ ABI silliness, this means fighting with 13 different gcc-X-base packages, and ensuring that everything that’s on the system is happy with the exact version of the installed libstdc++.

    I haven’t attempted to deal w/ libglib in this scenario, but replacing libstdc++ with libglib doesn’t seem like much of a win to me..

  5. I’m very interested in this and am willing to dedicate some time to it. I don’t have a whole lot of experience with vala, but I know the GObject system like the back of my hand.

    Anyways, whats the actual git clone url? I can’t seem to find it, and I’ve never cloned a git repo that’s hosted on debian’s site.

    1. @clone url:
      click on the link and read the page :) But it looks like the http clone url is not working. So you should use:
      git clone git://

      1. yeah i tried the http and it failed badly. I tried guessing the other, but added in a projects since it was listed in gitweb.

  6. I was thinking about something similar (maybe not as deeply, but still) and in Vala? I never thought someone would do such a low level thing in Vala. Anyway, I’d be pleased to help.

  7. That’s all boring stuff – languages, sizes, libraries…

    What about real innovations – will it be based on PackageKit?

    1. PackageKit seems to follow the rule “installation should not be interactive”, which is why it’s not accepted in debian

  8. I have the similar idea but my idea is not only making apt2 as library api functions. It is also several great improvements like automatically installing language packages and any package using mime type of file which user tries to open …. I have wrote a small technical document which describes all needed changes, but it require changes of dpkg format and I have not posted it in to dpkg mailing list yet because I am afraid that developers will not approve it. If you interesting I can send to you. Also I am interesting to take a part in the project but I don’t know Vala language, I am c/c++/python developer.

    1. Though I’m not a debian developer, I would be interested in what your suggestions are :)

  9. It would be useful to implement this using a client-server approach through dbus – similar to what PackageKit does. This way several clients would be able to work on one database without encountering the locked database issue.

  10. Thanks for working on an APT replacement, I really appreciate work in that direction, and it’s hard work.

    But I would appreciate it even more if you could lose the habit of insulting cupt in every post about APT2. That is just disrespectful towards other people like you who put work into a project, and takes away quite a big deal of the fun.

    The advantage of having more APT replacements is that it allows one to choose what works best for what they have. Cheer at another project, don’t sneer at them.

  11. a short comment:
    a good project is one well designed with clear goals & built as simpler as possible with no tons of dependencies.

Comments are closed.