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?"

Comments

easy.

[gl4ss]

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

Re:easy.

[toast0]

how are you supposed to install the gui with a graphical package manager?

why not have the package manager be all unixy and easy to abuse with pipes and such, so that if somebody wanted a graphical front end, it could happen, but if somebody wants to just maintain their server through a terminal, they could too?

It has to detect..

[t3kad0n]

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

Debian Policy!

[reynaert]

The Debian Policy manual is the reason behind apt-get's magic.

Debian is almost perfect...

[Froze]

Except that there needs to be a catagory entry. What I mean is a way of getting all similar types of packages. For instance suppose I wanted to look at all thing "word processing", then I would get packages ranked from most applicable (open office, abiword, etc) down to quasi applicable ( vi, gnotepad, hexedit, etc).

What I've Loved

[MBCook]

I've used many many distros over the last few years, and I can tell you the things I like easily. Below are some of my top ones:

• Dependencies - This is probably the most important for me. The thing that makes apt so great is that it can do dependencies. Gentoo's emerge also does a great job of this. I haven't used an RPM distro in about 2 years, but back then they didn't do anything but complain that you needed some other package. YOU had to go find it. YOU had to go install it. YOU had to get IT'S dependencies, etc. It meant installing one package could take forever.
• Source - I like being able to easily build from source. With RPMs (at least in my expirence) it would build the package, then put it in some odd location and you'd then have to "rpm -Uvh" (or whatever) from there. Gentoo does a great job of this, but it's a source distro ;). Basically, when I install from source, it should install the package for me. If I only want to make some kind of binary that I can distribute, that should be a seperate command.
• Compatibility - RPMs never seemd to work across distros, quel suprise. This is one thing that I really like about slackware's .tgz files. They are nothing but a .tar.gz with some extra info, so no matter what system you use, you could just download the slackware .tgz and use it, right? Gentoo doesn't have packages, but "ebuilds". These are nice because they are small little text files, and your computer goes and fetches the latest version of the package (or whatever version is specified). It uses the standard source and it gets it the same way you might.
• The Unistall - This can be a PAIN. This is the one feature that, IMHO, makes packages better than source. If this doesn't work, why not take the extra 3 steps to use source? When I uninstall something it should be removed completely. No empty directories, it should offer to remove it's config files or back them up, it should offer to restore any files that it's changed, etc. Both Debian and Gentoo do a great job with this. I don't remember what it's like with RPMs very well.

I'll post more if I can think of them. Why does constructive criticism have to be so much harder than normal criticism? He he he. I talk alot about Debian and Gentoo because those are the two distros that I use regularly, and the package systems are a big reason for that. Packaging makes a difference. I'd probably run Mandrake if it wasn't RPM based. It's a great distro, but I just CAN'T STAND RPMs. Are they much better now than a year or two or three ago? Almost certanly. But I've been so soured to them by my expirence, it will be quite a while before I try them again; especially since I found apt and emerge.

The packager means more than the package system.

[cornice]

I've had success with RPMs, DEBs, EBuilds, etc. What really makes the biggest difference is the packager. Most major distros have pretty good package maintainers now. This wasn't always the case.

Now for me it's all about convenience. If I can use Debian, Gentoo or Mandrake+Ximian Red Carpet and keep my system up to date on a daily basis then I'm happy. This requires good packages and good mirrors. I throw Ximian in there becuase I've had a terrible time with Mandrake mirrors. Also if I can upgrade without running an install from CD then I'm happy. Debian and Gentoo seem to do this quite well. If I can avoid conflicts and install a couple versions of the same thing and keep it all straight, then I'm really happy. Gentoo seems to be making strides towards the last one but compiling everything isn't always an option.

For those of you using RH 8.0

[0x0d0a]

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

Package Management

[Tuxinatorium]

Well, I prefer Fedex for my packages... UPS sucks and priority mail is too slow.

I've said this before, but...

[tubabeat]

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!

Re:I've said this before, but...

[__past__]

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'd say that is a specific problem of RPM (or the way it's used in practice). It could simple look for an executable perl$PERLVERSION in $PATH, or even test the output of perl --version or something.

On the other hand, you'd better know when to stop with this, or you'll end up reinventing autoconf...

Better front ends

[0x0d0a]

I'd like to see front ends be a bit better. I was quite impressed with apt-get, and use it with RPMs on a RH system. RH's up2date is really awful -- it's sluggish, doesn't give much feedback on what's going on, fragile (rpm hangs or a download fails, and it isn't very smart about it), doesn't resume failed transfers, and doesn't let you download non-RH packages. It simply feels flaky, which is not good for a tool that, for many users, may be their only look into the management of their system.

Oh, and it grabs an exclusive lock on the rpmdb the entire time the thing is downloading. I *really* think this is a bad idea -- at the very least, there should be an option to flip this off. Novice users aren't going to be running rpm manually anyway at the same time, and more experienced users *really* get annoyed when they can't query or modify in unrelated ways the system while up2date is slowly sucking something down over a modem.

Apt-get is nice...if there isn't something like it, it might be a good idea to have a Red Carpet-like GUI for it to make it really appealing to new users. Hell, most people don't use Windows Update because they consider it too intimidating or don't know about it...

Re:Better front ends

[ctr2sprt]

As someone else noted, all of Debian's tools also do the same dumb blind-locking. Extremely annoying. That needs to go out the window: lock when you need it, never at any other time.

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.

Tip for RPM users

[0x0d0a]

RPMs never seemd to work across distros, quel suprise. This is one thing that I really like about slackware's .tgz files.

And some things aren't RPM-packaged.

One tool that *no* RPM user should be without, IMHO, is checkinstall. This runs a normal "make install" after you're done with ./configure and make, but monitors what locations files are being "install"ed to. It then builds an RPM package and installs it. This lets you cleanly uninstall tarballs, and handles library dependencies. In many ways, it gives you the flexibility of Slackware's approach with the nice features of RPM.

checkinstall

[swillden]

It may be just me, but I never bothered to build my own RPMs or DEBs when I was using Linux.

I nearly *always* build DEBs for my Debian boxes (well, for the occasional app that Debian hasn't already packaged), and I've never bothered to learn how debs are made. How? checkinstall

To use it, you just run:

./configure <appropriate opts> && make && sudo checkinstall

checkinstall will run "make install" for you, but will do it in a chroot environment, see what got installed where, build you a DEB that will do it and then run "dpkg -i" to automatically install the DEB for you.

And, of course, "aptitude purge <pkgname>" will get rid of it all.

11 good suggestions...

[mindslip]

1: Auto-xsu when trying to install/remove/update (such as the way red-carpet does)

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

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 .spec edits.
11b: Same for a tar.gz file with a spec in it... Edit the spec, re-tar the files.
11c: Enforce proper .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
11d: Auto-move/copy the tar.gz to /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!

Ok, so hope these will help. I know they'd certainly help me!

mindslip

Rollback.

[Zapman]

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.

Re:Rollback.

[__past__]

Something similar: It would be nice if the package management system would remember what I only installed as a dependency of something else, and would remove it when I deinstall the other package (after asking me, of course).