Package management in Gentoo Linux [LWN.net]

Package management in Gentoo Linux

Posted Jul 6, 2007 16:39 UTC (Fri) by cventers (subscriber, #31465)
Parent article: Package management in Gentoo Linux

What I think would be really neat is if these package managers had the
following:

1. Dynamic library tracking, because revdep-rebuild SUCKS! The package
manager knows what binaries it is installing into the live system, it
should be able to 'ldd' and remember from then on. The hope, of course,
is that the package manager would be smart enough to recompile any
packages dependent on the library.

2. Ebuild cache... periodically, Gentoo deletes ebuilds from the portage
tree. The problem is that you may have an old version of some package
that Gentoo no longer supports which depends on a library you want to
upgrade. If you still have the source, Gentoo should happily rebuild the
old (no longer supported) version of the software against the new
library.

The lack of this ability leads to occasional frustration when you have to
upgrade a library due to a security vulnerability, only to discover that
you now have to upgrade other packages just because Gentoo deleted the
ebuild for the version you were using.

4. A better etc-update. The one that is included should be taken out back
and shot :P

Gentoo is great, but in some ways I feel like it is just the tallest
midget. I really wish I had the time to help on the code, because I feel
that these features would greatly enhance the OS. A guy can dream, can't
he?

(Log in to post comments)

Package management in Gentoo Linux

Posted Jul 6, 2007 19:56 UTC (Fri) by dberkholz (subscriber, #23346) [Link]

Great suggestions!

- It needs to do more than just ldd, so it can handle all types of languages. For example, Perl or Python modules need to get handled a bit smarter. Various people have worked a little on this problem, but nobody in Gentoo has done a good job of finishing it.

- The ebuild cache as it exists now is a little subpar. You've got the current ebuild in /var/db/pkg/, or you can look in the CVS Attic via your anoncvs checkout or http://sources.gentoo.org/.

- I really like the transactional idea.

- Some other possibilities do exist for updating your config files such as dispatch-conf, conf-update, cfg-update (all of which are part of Portage itself or in the main Portage tree) or the new etc-proposals (sunrise overlay). Try 'em out.

Package management in Gentoo Linux

Posted Jul 8, 2007 20:29 UTC (Sun) by dirtyepic (subscriber, #30178) [Link]

3. Transactional upgrades. If you want to upgrade a slew of software, merge all the files into a temporary holding directory and wait until all packages and their dependencies have successfully compiled before updating the live system. Having to chase down build failures in the middle of an "emerge", when your system is currently in a broken state, is irritating.

Interesting idea, but I'm not sure how that would work or why introducing massive changes to the system all at once rather than incrementally would help anything. Would you link to the system libraries or to the ones you've just built in the holding area? What happens when those libraries are suddenly relocated or overwritten?

The best way to handle updating is one package at a time. If something breaks, then you only have to deal with that package. Blindly running emerge world is usually what gets people into trouble in the first place.

4. A better etc-update. The one that is included should be taken out back and shot :P

I don't honestly know why it's still around and the default. dispatch-conf forever.

Package management in Gentoo Linux

Posted Jul 10, 2007 16:00 UTC (Tue) by rise (guest, #5045) [Link]

If you're not using static binaries anywhere in the process (a big if) a CheckInstall/installwatch-style solution might work. Basically it uses a library preload to catch all file accesses and redirect them to a temporary area while overlaying the results over the actual filesystem. Then it bundles up all the changes it saw into a package. This is a nice but sub-optimal solution for software lacking true packages, though I use it heavily to make random source-compiled software trackable and uninstallable. However it should work nicely for transactions - just delay committing the overlay until the process completes properly.

AUFS for Transactional Upgrades

Posted Jul 12, 2007 20:19 UTC (Thu) by hathawsh (guest, #11289) [Link]

For near-transactional upgrades, consider an aufs-based chroot. (Note that this idea applies equally well to any package manager.) Here is someone who tried it:

http://blog.vrplumber.com/1889

AUFS for Transactional Upgrades

Posted Jul 19, 2007 15:48 UTC (Thu) by ferringb (subscriber, #20752) [Link]

Actually I tried something similar a while back; unionfs sandboxing of the phases to try and get the ability to truly track/reverse what pre_inst/pre_rm were upto, and track ebuilds builds where userpriv restrictions were in effect; problem I had was that it always wound up making gcc spew in a non-obvious way for compilation.

Either way, interesting to see someone playing with it still (nature of some of the phases, it's kind of required long term imo).