The future of package manager.

I truly believe that dpkg ( Debian/Ubuntu) and rpm ( Red Hat/OpenSUSE/PCLinuxOS) are all dated package managers which have not evolved enough with time. Not to undermine any of the two -- they have been performing well since ages and have given us some excellent distributions.
However, like everything, technology also ages; enters the newer breed like emerge(gentoo/Sabayon), pacman (Arch/Frugalware), PBI(PC-BSD) and conary(Foresight/r-path).

Unfortunately Gentoo development team has gone crazy and are busy in doing everything but development. Check out a small review of the other three by lazytechguy.

Of the three mentioned Conary seems to be the most technically advanced. I came across an interview with the developer of Foresight Linux and was impressed by the description of Conary by the dev. Check out some of the fine points.

1. Foresight Linux seems to have an interesting release cycle, can you explain it in-depth?
   - Our package manager, Conary, follows many of the principles found in version control systems. Not only does it maintain the source of our packages in the same place as the binaries created, but there are branches. So we have development, QA, and release branches. We are able to do our development on the development branch, without affecting our users. We then promote packages to our QA branch, and test them as a group. The entire operating system is defined in a group, and the packages are built together for optimal compatibility. We test the group of packages together, as a whole, when the QA cycle is complete the entire group is promoted to the release label for user consumption.
   NOTE: Foresight is the first distribution to make a release immediately after a GNOME release.
2. When did you come to realize that Foresight Linux was needed?
   - Well mostly frustration with existing distros. At the time I was working for a large enterprise where we managed a very large scale linux infrastructure. We struggled with maintenance and deployment issues, as well as the “we have to customize red hat mentality”. I always hated rpm spec files, and hated that our environment was never easily reproducable. Using Conary, I was able to very quickly build a distro that was made up of what I defined as of proper desktop OS using the latest GNOME.
   NOTE: Foresight follows a rolling release so we need not wait for 6 months to get a new package as in Ubuntu or one year in case of Red Hat
3. How does Conary differ to other popular package management systems (such as dkpg, Portage, and Yum) and why is it a better method of doing things?
   - Whew… where to start Conary does so much more than legacy packaging systems such as apt(dpkg) and yum(rpm). Conary melds version control concepts into package management. Not only on the build/packaging side of things, but even for system maintenance. Conary stores sources with the binaries, in the same package, supports branching, merging, etc. On the flip side of that, Conary does some other very nice things. For example, every operation is a transaction. So you can actually rollback your last update or even all the way back to when the system was installed. And, these rollbacks contain local changes that get merged. Also being transactional, Conary breaks updates into smaller “jobs”. These jobs are dep complete, so if at anytime an update fails Conary will rollback to the previous job leaving your system dep complete and fully functional. Conary also breaks packages down into manageable components, :runtime, :lib, :devel, :devellib, :doc, etc. So unlike other packaging systems, where you might have 2 packages, firefox and firefox-devel, Conary would have one package with the devel headers split into firefox:devel. This is a great thing, you no longer end up installing -devel packages from random repos in your sources.list just because it looks like a newer version. The devel headers are just part of the same package, you just don’t have to have them installed. These components combined with rich dependancy information really shines.
   NOTE: This means that even if we subscribe to dev repository we will be shielded from a development version of an application.

All the above statements( except for my comments in form of NOTE) are copied verbatim from fscking.com.
Enjoy the full article there.