GoboLinux's recipe for delicious package management (Linux.com) [LWN.net]

GoboLinux's recipe for delicious package management (Linux.com)

Posted Feb 15, 2007 21:58 UTC (Thu) by munozga (subscriber, #26290)
In reply to: GoboLinux's recipe for delicious package management (Linux.com) by nix
Parent article: GoboLinux's recipe for delicious package management (Linux.com)

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

(Log in to post comments)

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.