Slashdot Mirror
What Package Management Features Do You Value?
0x0d0a asks: "Slashdot has now had a number of articles on package management. Strong opinions about the management approaches of Red Hat, Debian, Gentoo, Slackware, and BSD have all been expressed, some quite negative. What suggestions do you have for improvement? What features do you value in a package management system, and in what areas would you like to see additional functionality?"
it has to be easy in overall.
easy to install stuff the first time(type one line or press one button and it'll figure out the rest).
easy to remove that stuff without it leaving other stuff unworking.
easy to keep up-to-date.
well.. apt-get fits this bill at the moment for me.. i don't care much of compile-locally-optimized-whizmo jizmos.. nor don't i think that downloading binaries from debian is a security concern anymore than downloading sources through some portage system(heck, i'm wouldnt check the source anyways).
and i find dselect comfortable to use and easy to find software from..
world was created 5 seconds before this post as it is.
It has to detect if the libraries it needs have the same functionality as the newer ones I have. Needing version .40 of a library and not accepting library version .50 if it works the same as version .40. My perfect package manager wouldn't take many hours of frustration to make your own packages. :)
The Debian Policy manual is the reason behind apt-get's magic.
The rpm version that ships with RH 8.0 is pretty buggy and can lead to lockups. RH has an unsupported fixed version of rpm that fixed these problems for me (I was only impacted by one of the bugs). They haven't put out an official update yet.
Note: do *not* upgrade to the version of RPM in Rawhide or Phoebe, RH's current beta. It's a *pain* to get back -- you get moved to hash-version 8 if you --rebuilddb at any point, and db4 as packaged by RH doesn't grok hash-version 8. You'll need to grab db4 from Sleepycat and use it do dump your rpmdb and reload it with RH's db4 if you want to get back (this happened to me).
May we never see th
There's little point standardising on rpm (because thats what the LSB says) or any other package management system unless packages are named consistently. I can't pick a Red Hat rpm and have confidence that I would be able to install it on Mandrake or SuSe or ... because I can't be sure that the dependencies will be satisfied as some packages have different names (one example perl-base-5.8.0 on Mandrake is called perl-base-5.800 on RedHat, enough to screw up a dependency check)
This doesn't really bother me because I'm quite happy to build from source (or even make my own rpms if I've got many installs to do) - but to be honest unless a package management system can be relied upon to work always then its isn't working properly and that is a bug (even if its a design bug rather than an implementation one) not a feature.
I guess maybe a solution is for rpm (or whatever) to save version numbers for each file it installs and for dependency checks to be strictly only on files rather than packages. A more sophisticated rpm wrapper (like urpmi) could then map failed dependencies back onto the appropriate package for the distribution. I suspect this is nowhere near as trivial as it sounds!
"Linux is a serious competitor"
- Steve Ballmer, Chief Executive Microsoft Corp.
1: Auto-xsu when trying to install/remove/update (such as the way red-carpet does)
.deb / .mdk / .whatever-distribution madness and stick to the LSB or some such Linux standard... or at least auto-detect distribution and run appropriate script / install appropriate architecture files
.spec edits. .tar.gz filenames... it's quite common to find the tar filename different from what the .spec expects. Create a way to double-check the correctness of the spec /RPM/SOURCE ...I always do a build on a tar.gz and it says it can't find the tar.gz in /RPM/SOURCE! Well, heck, use the one I'm rebuilding and *move* it there!
2: Auto-get dependancies off popular mirrors (like fr2.rpmfind.net which is far more up to date than www.rpmfind.net)
3: Be able to list "--forced" and "--nodeps" packages, and remove / update / update dependancies of just those packages (i.e. clean up your system)
4: Be able to list (-qa) with wildcards instead of having to -qa | grep whatever
5: Standardize and *enforce* some sort of package topic structure, say based on Freshmeat's or Sourceforge's
6: Be able to uninstall en-masse, any packages with no dependancies (i.e. clean up unused libraries, etc.)
7: Stop this
8: Curses interface for console (wouldn't "red-console" be nice?!?)
9: Require packages to properly handle gnome/kde/etc. menus (Hey... even *windows* lets you *find* the stuff you install!!!)
10: Be able to read and manipulate the packages installed on a system, when you've booted from a rescue disk (this is probably most important... booting off a rescue, then chroot'ing isn't always enough to get at the package databases, var directories, etc. db and other dependancies that RPM itself uses need to be *statically linked into RPM* so you can use it on a nearly-dead system.)
11: Handle -bb and --rebuild better:
11a: if you download a src.rpm file, and need to rebuild with a modified spec, you practically have to rebuild the src.rpm with the
11b: Same for a tar.gz file with a spec in it... Edit the spec, re-tar the files.
11c: Enforce proper
11d: Auto-move/copy the tar.gz to
Ok, so hope these will help. I know they'd certainly help me!
mindslip
People have some good points, but one thing that package managers need to understand is rollback. ie: I had gnome 1.4 installed. Worked well. I upgrade to gnome 2.1. 2.1 might just turn out to not do what I need at the moment, or it might be incompatable in an important way. I should be able to 'roll back' the system to 1.4 without performing major surgery.
Yes, this will take more disk space (to hold the old versions of all the files, and the metadata to restore them). But in an enterprise environment, you need it. Sun has been doing this for years with their OS patches, and we should be able to steal it for packages too.
Zapman
Next up, apt-get is bad about handling low disk space. Try apt-get upgrade when you're going from stable to unstable. You need to download 100MB+ of packages for a reasonably complete install. That's more than many people have in /var, which is where apt-get stubbornly insists downloaded files must go. If there's a way to change this, it's undocumented, because believe me I've looked. So apt-get needs to be smarter about downloads. There's not 100MB available? Fine, figure out how much is available and download that much. Install it, delete it, and then download the next chunk. Low disk space situations can actually cause serious problems because dpkg apparently doesn't check free space correctly when it's installing packages. It unpacks it into a temporary directory in /var, runs the configure script, and then tries to copy it to the final location. This is the right way to do it, except that because there's no disk space checking, you can run out of disk space anywhere during that process and get in trouble (like if it happens when replacing libc, for example). So package managers must check to make sure there's enough free space every step of the way, and it must be able to roll back the part of the install that it had already done. I don't expect this to be totally perfect - there will always be race conditions on a multiuser system here - but anything is better than what dpkg has now.
Another important thing is smarter handling of version numbers in the package database. Debian tends to suffer from problems related to this, which is why you see packages named "lib2" and "lib3" (e.g., two completely distinct packages, rather than two packages which happen to have different versions). The reason for the double packaging is that often a program relies on a specific version of the library and it's convenient to have both libraries installed at once. But the package database and versioning system doesn't support two identical packages with different numbers: the software just blindly tries to install the newest one, and bails if it can't do that and still resolve all dependencies. This causes all the sorts of problems RPM users often see, which is two functionally-identical but differently-named packages causing dependency errors, loops, or other problems. It also draws out the single most frustrating aspect of package management for the user, which is that they don't understand why they need a package and therefore don't understand the relevant differences between, say, glibc-2.3.1 and glibc-2.2.4. They usually don't even realize that those are the same package, just two different versions, and so they try to install both... usually with --force flags and disastrous results. Package managers, and packagers (the people), need to get rid of the ambiguity and make sure that users can always say "glibc" and let the package manager worry about the version numbers. This is what Debian was like for a long time, and I'd like to see it be that way again.
"Meaningful defaults" is also a good thing here. I like this about FreeBSD and RedHat. The configuration scripts aren't shy about making decisions for you. That's fine with me, as long as those defaults are sane (usually they are). What I dislike is when the package maintainer starts getting involved in policy (e.g. Debian and OpenSSH), or when the configure script wants its hand held every step of the way (default setting in Debian). Packages should also never have defaults which go against the standard system policy (e.g. Debian's OpenSSH enabling root logins by default, even though FTP, Telnet, and all other similar services do the reverse by default). There also needs to be consistency in the defaults for a package between versions, so users don't get caught off-guard by the change (lots of packages, sadly, are guilty of flip-flopping between defaults when they aren't sure which to use). If all else fails, put a syntax error in the configuration file to force the user to edit it by hand.
This may sound more like criticism than positive things, but I think these emphasize the good parts of package managers. Most of my complaints are about features incompletely or poorly implemented. I basically like working with packages on any modern Unix(-like) system. It's pretty trouble-free and usually Just Works. Most of my complaints are nitpicks or things that bug only power users; in other words, things to improve on in the future, since the great bulk of features have already been implemented and are working great. I think the reason for all the criticism, in my post and others', is that there're so many good aspects of modern package managers that it's shorter to list the defects than the great, useful, working features.