Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
GoboLinux's recipe for delicious package management (Linux.com)GoboLinux's recipe for delicious package management (Linux.com)Posted Feb 15, 2007 11:07 UTC (Thu) by hein.zelle (guest, #33324)In reply to: GoboLinux's recipe for delicious package management (Linux.com) by mgedmin Parent article: GoboLinux's recipe for delicious package management (Linux.com)
I'd be interested to see if they can make that work. It's a sort-of tried method, we used it at my previous employer to install a lot of software without administrator rights, on a shared directory. For some packages it's easy to automate, but for many others manual intervention is required. You need to figure out what to link and what not (only bin/* and lib/*? or include/* as well? Or man .. or info?). Then you have to worry about exceptions, packages that only need a small subset of the files they install in actual system directories, etc. Info tends to break unless you massage it to update the right "dir" file. Etc, Etc.
Uninstalling presents a new set of interesting problems: granted, throwing away the installed files is easy, but you still need to filter out the broken links that remain.
All in all that sounds to me like you'll need an installation script for each package anyway, either built into the makefile or separate. Then I don't see too much difference with .deb or .rpm packages.
(Log in to post comments)
GoboLinux's recipe for delicious package management (Linux.com) Posted Feb 15, 2007 14:35 UTC (Thu) by nix (subscriber, #2304) [Link] 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.
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.
GoboLinux's recipe for delicious package management (Linux.com) Posted Feb 19, 2007 14:58 UTC (Mon) by mmarq (guest, #2332) [Link] "" It's a sort-of tried method, we used it at my previous employer to install a lot of software without administrator rights, on a shared directory. For some packages it's easy to automate, but for many others manual intervention is required. You need to figure out what to link and what not (only bin/* and lib/*? or include/* as well? Or man .. or info?) ""
imho it wouldnt be that hard to automate, even for non-root accounts, if it were included in the LSB HFS. That is, the "figuring out" would be pre-determined, and only the App files(ex, lib, data) *Really Needing* root acess will be ones getting it.
Putting every App in /usr dosent do i nice job.
Worst is a *security treath*. Better would be to install every App *as non-root* in a special directory, and automate install from an ACL for what Apps files that would be needing root previlege, and at full discretion for what users and groups that will be having acess to what Apps files.
That install could be just a hardlinking script, not breaking POSIX, and so duplication would not be necessary. And better we could even re-install a different distro that most probably almost all Apps will work, that being i belive the original idea...
Portability could be 100% if that special directory could have several versions of the same App or several different versions of the same App.
But better than all this, is that it will be implementing a coherent form of the *Principal Of Least Authority* (POLA) into Linux World. Security would be much more improved from what might be seen at first sight.
|
|||||||||||