| |||||||||||
The Great Package Management ExperimentThe Great Package Management ExperimentPosted Sep 25, 2003 3:50 UTC (Thu) by torsten (guest, #4137)Parent article: The Great Package Management Experiment
I've fussed about package managers quite a bit, but there are several things I think they continue to fail to offer. *Install programs into subdirectories. *Recognition of source-installed apps (non-packaged, non-managed). *Soft symlink into the file system (prevents overwrites, etc). *Self-contained installation - no reliance on a script server. *Universality - should work on many *NIX. Torsten
(Log in to post comments)
How about portage, or even autopackage? Posted Sep 25, 2003 15:19 UTC (Thu) by alspnost (subscriber, #2763) [Link] Obviously, this article, excellent though it was, has no mention of Gentoo's portage system. I would rate this pretty much on a par with Debian; there's a massive range of packages ready-to-go; and upgrading the entire system involves, as with Debian, just a pair of commands.But beyond that, portage is aiming to cover some of the things you mentioned. Though Gentoo is source-based, future versions of portage should be able handle binary packages and source installation methods the same way. Multiple concurrent versions of the same package are already supported, and as for universality, I believe portage is already being "portaged" (sic) to Mac OS X and BSD. Well, it's a start! I work with Solaris, and I would dearly *love* it to have some of this technology; currently, it's an absolute pain to maintain. Anyway, the future is either portage, or possibly autopackage - that looks like it could be a killer, if widely adopted.
How about portage, or even autopackage? Posted Oct 3, 2003 7:35 UTC (Fri) by job (subscriber, #670) [Link] I'm sorry, but Gentoos package system is pretty far from Debian's. (I say this isa user who's been running both distributions for quite some time, and prefer Gentoo for desktop work such as mplayer in the example.) To start with, you need three different package tools as emerge in itself isn't very capable. Then there's three or four different ways of masking a package, so you may well have to go edit the package definition files (ebuilds) in order to install stuff. And since emerge in itself is lacking some features, there is simply no simple way at all to do certain things, such as upgrade a library AND all files that depend on it. You have to script it or do it by hand. I love Gentoo as a source distribution and an alternative to LFS (Linux From Scratch), but if package management is your game, nothing can beat Debian.
How about portage, or even autopackage? Posted Oct 3, 2003 9:53 UTC (Fri) by emj (guest, #14307) [Link] Well Debian really has a lots of diffrents ways to install packages. You have to use apt-get, dpkg, apt-cache, aptitude or wajig to get everything you want to have. Debian really lacks a tool that will give a good unified interface, but that isn't the UNIX way.. ;-)
The Great Package Management Experiment Posted Sep 25, 2003 17:00 UTC (Thu) by zooko (subscriber, #2589) [Link] I use GNU stow on my Debian system, when I want to build something from source:./configure --prefix=/usr/local/stow/bindlywhoop-v1.2 It doesn't do dependency management for you, but for some reason I rarely need it. Perhaps the things that I want to hack on and compile from source don't usually have dependencies.
The Great Package Management Experiment Posted Sep 28, 2003 23:17 UTC (Sun) by torsten (guest, #4137) [Link] ./configure --prefix=/usr/local/stow/bindlywhoop-v1.2 This method is defective. The path is hard-coded into some of the libraries and binaries. When you move the directory to another prefix, the package will fail (some packages fail, some don't).
The Great Package Management Experiment Posted Oct 4, 2003 14:11 UTC (Sat) by csh (guest, #15725) [Link] The proper way to use something like stow is this: % ./configure --prefix=/usr/local When you install, you use this command: % make prefix=/usr/local/stow/<package>-<version> Then when you stow the program, it will have normal paths like you would expect. If you aren't using a package with the GNU auto stuff, you'll have to do this step manually. I used to maintain my own system, and a set of patches for different packages to handle the dual nature of a "stowed" install.
Package manager features Posted Sep 25, 2003 17:53 UTC (Thu) by vonbrand (subscriber, #4458) [Link] *Install programs into subdirectories.What do you mean by this? Installing packages into /this/is/my/fave/bin/ will probably fail because they aren't found, or they don't find their pieces *Recognition of source-installed apps (non-packaged, non-managed). Please tell how you want the system to find out that of the 300 files changed today, 20 are in one package, 35 in the other, most of the rest is leftover junk from building, and then there are unrelated changes. *Soft symlink into the file system (prevents overwrites, etc). Dunno what you mean here. If you symlink, the original link is gone. *Self-contained installation - no reliance on a script server. What does this mean? *Universality - should work on many *NIX. Just compile RPM for it, and be done. Just the (very minor) issue of getting all *NIX people to use RPM for packaging... Debianites will come screaming for your hide, for starters ;-)
Package manager features Posted Sep 28, 2003 23:26 UTC (Sun) by torsten (guest, #4137) [Link] You obviously have no major experience with relinking or scriptable package installation. I imagine this is because you have not discovered the problems associated with rpm package management. Stay with your RPM's and be happy. All of the points above are understandable by any Linux techie who has dealt with system management issues, packaging, and package management. They are also valid points, which indicate the weaknesses in all the current package management systems.
Package manager features Posted Oct 4, 2003 8:06 UTC (Sat) by marv (guest, #15720) [Link] **Install programs into subdirectories.*What do you mean by this? Installing packages into /this/is/my/fave/bin/ will probably fail because they aren't found, or they don't find their pieces Mainly for user-land installs.
|
|||||||||||