| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
GoboLinux's recipe for delicious package management (Linux.com)
GoboLinux's recipe for delicious package management (Linux.com)
Posted Feb 15, 2007 14:35 UTC (Thu) by nix (subscriber, #2304)In reply to: GoboLinux's recipe for delicious package management (Linux.com) by hein.zelle
Parent article: GoboLinux's recipe for delicious package management (Linux.com)
The rules I use are simple: symlink everything where the target is an unexported local directory unless it's in a directory shared by many packages, in which case mkdir() and symlink the contents; mv(1) when the target is an exported local directory (and take care because you'll need some other way to clean up that directory when packages are uninstalled); rm(1) when the target is a directory imported from somewhere else.
As for cleaning up the broken links, that's a job for GNU stow or Depot.
I handle all of this with a ~200-line general postinstallation script (that runs stow, gzips manpages and info, copy-and-strips debugging info into separate files, massages .la files, and so forth) and with very small per-package installation scripts. 95% of packages need no such scripts at all, or need at most a line or two of configuration to tell it `install using DESTDIR, not prefix' or something like that, all driven by a state machine written in the ksh subset of zsh. With that in place, it's a matter of one command to build and install something, and thanks to quilt and freshmeat, upgrading even patched packages is a breeze.
I really should make this heap of scripts publically available, I suppose.
(Log in to post comments)
GoboLinux's recipe for delicious package management (Linux.com)
Posted Feb 15, 2007 18:59 UTC (Thu) by thedevil (guest, #32913) [Link]
>> As for cleaning up the broken links, that's a job for GNU stow or Depot. <<
I tried this scheme too, long ago before I became a Debian addict. This really *is* the catch, even with tools like stow, because of INefficiency. stow -D can take forever even for a single package. I guess that is because removing the symlinks destroys access locality.
GoboLinux's recipe for delicious package management (Linux.com)
Posted Feb 17, 2007 1:56 UTC (Sat) by nix (subscriber, #2304) [Link]
Well, it's because it has to readdir() every directory in the system. Ihave a tiny patch that makes stow use the d_type info, so that at least it
doesn't have to stat() everything as well. But still it blows the cache,
yes. (That's why you can -D / -R several things at once.)
GoboLinux's recipe for delicious package management (Linux.com)
Posted Feb 15, 2007 21:58 UTC (Thu) by munozga (subscriber, #26290) [Link]
And how does all of this stuff integrate with Perl/Python/Ruby packages and their 3rd party repositories (CPAN, Gems, and not sure what Python uses)?
I think the article mentions the use of ldd for tracking library dependencies. What about the dependencies that cannot be resolved by ldd?
The article didn't go into how it keeps multiple package versions separated, I'll have to check that out. I always end up doing that the old school way (install to /opt and write a shell wrapper that include the correct library with LD_LIBRARY_PATH--which is *evil*--for every app I want to use the alternate library).
GoboLinux's recipe for delicious package management (Linux.com)
Posted Feb 16, 2007 3:27 UTC (Fri) by k8to (subscriber, #15413) [Link]
Offtopic: python doesn't really have a packaging dependency repository, and I vastly prefer it this way. Code that really is in commmon need migrates into the standard distribution, and code quality and developer focus tends to win over convenience.
Yeah, it doesn't offer the same level of quick-start for specalized tasks, but I really prefer my distribution managing this stuff anyway.
Ontopic: The whole package tracking via symlink has no appeal to me. The hard part of integrating a set of packages is when you actually integrate all the programs into a single namespace, which you have to do in a symlink forest as well as plain file installation. The difference is just whether a symlink forest or a specialized database keeps track of who owns what file.
The specialized database is a _lot_ faster. It seems cute that the symlink forest is so directly inspectable, and if there wasn't a fairly high complexity cost for the common (runtime) use case, I would favor the direct inspectability of the approach. But the added complexity for non-management tasks makes it something I would not ever deploy.