What Package Management Features Do You Value? 70
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?"
easy. (Score:4, Insightful)
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. (Score:1)
My ideal package manager would be where everything installs graphically, like in windows, or like mozilla. It installs in a location in the filesystem specified by the user. And this should be predictable, no making extra folders in folders like windows apps do. If something has dependencies it should check for them and automatically upgrade/install them if they are not present without ruining compatability for any other app.
There should also be a seperate piece of software with a list of all installed packages organized by type of application. The packages should have real names like "Mozilla Version 1.2.1" not "mozilla-i686-pc-linux-gnu-1.2.1-sea". From this graphical application I should be able to automatically upgrade install and remove new packages. The program should also "just know" where to get updates to packages and how to install them.
Not only would this be a vast improvement in ease of use over current linux options, but it's easier than windows. And the only thing I've seen yet that's easier than windows is knoppix. So it's saying a lot.
Re:easy. (Score:3, Insightful)
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?
Like windows (Score:1)
Re:Like windows (Score:2)
(yes i'm being a prick, but some people legitimately use serial consoles for things, and a graphical package manager wouldn't work well for that)
It has to detect.. (Score:4, Insightful)
Re:It has to detect.. (Score:2)
Debian Policy! (Score:5, Insightful)
Re:Debian Policy! (Score:2)
stability (Score:2)
Something as important as a package manager can't be this buggy [redhat.com].
For those of you using RH 8.0 (Score:3, Insightful)
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).
Debian is almost perfect... (Score:4, Interesting)
Re:Debian is almost perfect... (Score:2, Informative)
Except that there needs to be a catagory entry.
Easy: Install the aptitude front-end (apt-get install aptitude) and select New Categorical Browser from the Views menu.
What I've Loved (Score:5, Interesting)
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.
Re:What I've Loved (Score:2)
I can understand and even live with binary RPMs not working across distros. I find it really annoying, however, that *source* RPMs are frequently not buildable on other distros. Mandrake's and PLD's frequently don't rebuild for use on RH, which is quite frusterating. They use slightly different macros in their
This is an area where standardization would make things *much* better, particularly since the differences between the formats isn't that big.
Tip for RPM users (Score:5, Informative)
And some things aren't RPM-packaged.
One tool that *no* RPM user should be without, IMHO, is checkinstall [asic-linux.com.mx]. This runs a normal "make install" after you're done with
The packager means more than the package system. (Score:3, Interesting)
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.
Good naming convention, good removal support (Score:2)
Also, I like a package manager that does a decent job removing packages. If I want to completely be rid of pptpd, all I should have to type is remove pptpd, and not have to worry that it left a million directories and configuration files sitting around.
Finally, I prefer a package manager that lets me override dependencies if I wish. For example, say I want to use pptpd. This requires ppp, but the version of ppp installed is only 2.0. I need 2.1, so I'd like the ability to somehow force the package manager to ignore the fact that ppp isn't installed so that I can install pptpd through it without having two versions of ppp cluttering things up.
Package Management (Score:3, Funny)
I've said this before, but... (Score:3, Insightful)
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... (Score:3, Informative)
On the other hand, you'd better know when to stop with this, or you'll end up reinventing autoconf...
Re:I've said this before, but... (Score:1)
You're right, it is a specific problem with the way its used in practice. But on the other hand it could also be argued that the fact such a situation can occur is down to flawed design.
It could simple look for an executable perl$PERLVERSION in $PATH, or even test the output of perl --version or something.
It could but that would be horrendous to implement so that it worked for everything any package might depend on (-v --version -version etc. etc. and then parsing the output!).
I'd be interested to know whether this is just a problem for rpm (after all rpm is probably supported by more distros than any other solution)or whether other package management systems suffer the same problem. For example can you install Debian packages on other distros that use apt-get (without running into dependency problems etc.)? P.S. I quite like rpm (but then I have used Solaris pkgadd, at least with rpm the package names give some clue about what they contain!)
Re:I've said this before, but... (Score:2)
It could revert to the "check if this RPM is installed" if any other test is too difficult.
Checking directly to see if a new enough version of a shared library exists, rather than checking to see if it's RPM is installed, would be a huge win.
uPM... (Score:2, Informative)
I would look for uOS [u-os.org], the distribution based on the package manager to rise above either Debian or Gentoo (both of which I love, btw). It is still early in development, but it seems to work well for me.
Re:uPM... (Score:2)
Make it easy to build packages (Score:2)
That is one of the reasons for me to like *BSD so much: Writing a port is not much harder than saying where you got the sources from and what files it does install (and that part can be automated, even), so it actually saves work keeping a nice, clean system. It may be just me, but I never bothered to build my own RPMs or DEBs when I was using Linux.
checkinstall (Score:4, Informative)
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:
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.
Re:checkinstall (Score:2)
Re:checkinstall (Score:2)
I immediately started searching for an RPM equivilant and found that checkinstall works for RPMs, .debs, and Slackware.
FYI, checkinstall can be found here [freshmeat.net]. This and apt4rpm [sourceforge.net] makes admining Redhat machines a lot more fun.
Re:checkinstall (Score:1)
Mandrake packages are on rpmfind, you need both checkinstall [rpmfind.net] and libcheckinstall1 [rpmfind.net] [Note they seem to have a circular dependency so you need to install one --nodeps]
Re:checkinstall (Score:2)
I wonder how it gets on with dependencies etc.
It ignores them.
Note they seem to have a circular dependency so you need to install one --nodeps
Been a long time since I used RPM, but... I believe you can install both of them with one invocation of rpm -i, and then you don't have to do the nodeps thing.
Re:checkinstall (Score:2)
It creates dependencies at install time for stuff that can be determined with ldd...so if you try to uninstall a library package that the new package depends on, RPM will complain.
Granted, this doesn't help if the packaged program calls an external program through fork()/exec(), but it sure beats nothing.
Mandrake packages are on rpmfind, you need both checkinstall [rpmfind.net] and libcheckinstall1 [rpmfind.net] [Note they seem to have a circular dependency so you need to install one --nodeps]
Weird -- can't see how libcheckinstall would depend on checkinstall. Anyway, you can handle circular dependencies by installing both at the same time. RPM will work out whether things are kosher.
Re:checkinstall (Score:2)
A side effect is with only a little bravery, you can usually slightly modify an ebuild to work with a new version of something, sometimes as easily as just renaming the ebuild file, and still be very confident that the uninstall of the old version and install of the new version will be perfectly correct, despite the fact that no "official" distro guardian is even aware of your ebuild.
Many people are not aware these things exist, but given their wide (if quiet) availability, users should consider the use of some kind of sandbox during installation a requirement for any distro management system they are considering.
Better front ends (Score:3, Interesting)
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 (Score:2)
i'm sure there are flags to dpkg and rpm to ignore the lock if you really wanna do two things at once
try using... (Score:2)
Re:Better front ends (Score:3, Insightful)
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.
Re:Better front ends (Score:1)
I have also run into this situation (think firewall box with tiny old 400mb hd). I just mounted a network share, pointed a simlink (/var/cache/apt/archives) to it and went on my happy way. Could be more difficult if the box is not networked, but those seem to be quite rare in Linux land. If you have the disk space in another partition; even easier!
As to locking, agreed! That is very frustrating!
Re:Better front ends (Score:1)
I believe you, but it's not undocumented. Try apt-get -o dir::cache::archives=/some/other/dir ...
or setting the Dir::Cache::archives setting in /etc/apt/apt.conf
Or, like the other poster said, symlink the archives directory to the other partition. I don't have an easy answer to the other parts about apt-get's desire to download and upgrade all at once, but others might.
Re:Better front ends (Score:2)
Package managers the worst part of Linux for me (Score:2)
I do not understand this, but graphical package managers have been the one single consistent failure for me in Linux, since Redhat 4.2.
Every single graphical package manager I've ever tried, with the emphasis on tried, to use has failed miserably for one reason or another. Red Hat 4.2's package manager seg faulted. In my Debian era, the Debian graphical managers were the only programs to consistently crash on me, once even leaving the system databases in an inconsistent state. kportage on my current Gentoo system segfaults every time I actually try to install something; I can browse the ebuilds and look at them, but not touch. Mandrake's graphical manager that I used somewhere around 7.0-ish would occasionally fail to segfault long enough to install a package or too, but it too would bomb out miserably, potentially corrupting files on the way out.
I've never understood why something that you'd expect to be the linchpin of a user-friendly distribution has always failed so miserably and so downright reliably for me over the years, over all the computers, all the distros, and all the install options I've tried for them. Fortunately, there was dselect, apt-get, and now emerge which provide good enough text-based utilities.
(I don't mind at all text-based utilities for installation. But graphical browsing of the available packages, by category, with a pane for the category, the description, the metadata, etc. is much nicer then anything you can do in text when you're just wandering around the distro seeing what is available.)
GUI integration (Score:2)
Yet Another Way (Score:2)
I want to be able to do "./configure && make && make install" and have the configure script look at a DEPENDENCIES file with URLs to resolve missing dependencies automatically. Such a system would be distro-independent and would not require packages to ever be created. If the process was this consistent, GUIs could even be created so the user doesn't even have to know what's going on.
Just a thought from a guy that really hates package managers.
Re:Yet Another Way (Score:2)
No it wouldn't and yes it would, respectively. Distros have standards about where files go, and files in the wrong place can cause unexpected and difficult to diagnose failures. Moreover, if you don't notify the package system of these rogue programs your DEPEDENCIES files created, you're liable to end up with another instance of them on your system. In that case, the least of your problems is the wasted disk space; the odds of one or both of them stomping on each other's configuration files or binary compatibilities or something are extremely high, even for one package. Libraries could be a complete disaster here.
As the AC sibling to this points out, you might consider Gentoo. Learn a little about how to twiddle ebuilds when you need to and you'll go a long way towards what you want, probably.
Slackware (Score:2)
Upgradepkg doesn't work as easily as it ought too, and when the distro changed to 8.x is actually got much worse because of the naming convention change.
I am also impresses these days with Gentoo...and its ebuilds...the only thing I think they are missing there is the way they handle upgrades...while it think is great they don't wonk your current config files...I really think it would be better to add intelligence to merge the old config files and whatever new might need to be added during the emerge of an upgraded package.
The only system I have used that I absolutely hated is the initial install of Debian...way to hard to use that system and totally not intuitive.
11 good suggestions... (Score:3, Insightful)
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
Re:11 good suggestions... (Score:2)
It exists... there's a channel for Red Carpet in (where else?!) Red Carpet.
You can now do pretty everything you did via the GUI, from command line. Sub/Unsub from channels, bring your system up to date, search for new packages to install, etc...
Rollback. (Score:3, Insightful)
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. (Score:3, Interesting)
The ultimate test (Score:1)
For me the ultimate test was forcing some package installs and totally FUBARing my box, then managing to get to a console and doing an "apt-get -f install" and having apt-get magically fix all the things I broke. Thumbs up, Debian.
Sensible defaults for idiots. (Score:2)
Mind you, I don't mean that the package silently installs to a pre-determined location automatically. Rather, it steps through the "usual" configuration values, but has sensible defaults for them such that a person doesn't need to override it under normal circumstances.
It makes it easy for someone like my brother to install software without shooting himself in the foot.
Possible improvement (Score:2)
Then you slap an "OK" at the top.
And, of course, retaining a non-interactive mode would be nice as well, where the defaults are simply used.
The Ports collection (Score:1)
Downloads the source, compiles, applies patches, and you are good to go. I never really had to uninstall much, but I think it worked well for that as well.
System V Package (Score:2)
pkgadd/pkgrm/pkgtrans/pkginfo
They work fine.
What, you mean you don't like figuring out that SFWgcmn is the "Sun Freeware GNU Common Utilities" package?
--NBVB
Needed Security Features (Score:2)
1. Revisioning. The ability to use different patch levels or versions. The ability to see how much space these different versions are taking up. Hard drive space is cheap, and I'm amazed an enterprise customer hasn't demanded this yet from Red Hat.
2. Security Policy. RPMS and other package formats sometimes come with scripts to do necessary post-install stuff. It would be nice to have a seperate userspace library to handle the 'common' things that might be in these scripts like running ldconfig or mkfontdir. This way, it would be simple enough for the rpm tool to give you a rundown of what 'actions' needs to be done to install this application security-policy wise. Ideally most scripts would become superfluos and only used it really odd situations. And in those odd cases you can read through the script yourself.
Re:Needed Security Features (Score:2)
1. Revisioning. The ability to use different patch levels or versions. The ability to see how much space these different versions are taking up. Hard drive space is cheap, and I'm amazed an enterprise customer hasn't demanded this yet from Red Hat.
rpm's --repackage feature appears to have this intention behind it. Unfortunately, it doesn't appear to work here as the GPG and MD5 signatures aren't redone.
2. Security Policy. RPMS and other package formats sometimes come with scripts to do necessary post-install stuff. It would be nice to have a seperate userspace library to handle the 'common' things that might be in these scripts like running ldconfig or mkfontdir. This way, it would be simple enough for the rpm tool to give you a rundown of what 'actions' needs to be done to install this application security-policy wise. Ideally most scripts would become superfluos and only used it really odd situations. And in those odd cases you can read through the script yourself.
RH have begun to do this with things like chkfontpath, chkconfig, so I think they're aware of it...
--
Auto/Online Update (Score:1)
Re:Auto/Online Update (Score:2)
I can see the pr0n industry wanting to patent that one... :-D
A fixed set tool set (Score:2)
RPM and APT/DPKG depends on too many external tools.
The package manager does most of the install/uninstall tasks by itself such as copying the file to the correct location, but to do the final install many packages depends on a preinstall and postintall scripts (and ditto for uninstall).
The necessities of these scripts shows that the built in mechanisms of the package manager are not sufficient for all packages, so the package maintainer writes a script to add the missing pieces.
These scripts can be a mess, usually written as a Bourne script or bash script, and depends on many tools such as sed, awk, perl, python, grep, ++++. Remove awk and many packages will fail during installation.
To list all scripts on a RPM based system try:
rpm -qa --triggers --scripts
Almost every time I have seen a problem with a RPM package, it has been a bug or a missing tool in one of these scripts. I have been told that the same goes for DPKG (can someone confirm this ?)
A better package manager should have very strong mechanisms for doing all sorts of things (such as installing an info page, removing old log files, or editing a configuration file). Look trough the scripts to get an idea of what is necessary. Then use one (and only one) script language without any external dependencies to write the remaining scripts (perl or python comes to mind, but an even purer solution would be to build in a small and powerful script language into the package manager).
Verify (Score:2)
One of the features I like about rpm is its --verify option, which checks if files in a package has been modified. Very useful - plus it informs you if a file is a configuration file - so those file changes can be ignored. verifying the integrity of a whole installation is just a small matter of a bit of awk to weed out the config files - then looking though the files that remains.
Automatic checking of GPG signatures and md5sums - also vital.
Freshening of packages, like the rpm -F, and query options that let you see what files belong to what package, and also ways to easily check what depends on what.
Could be done betterBetter automatic dependancy resolution. apt-get for rpm is available, but neither it, nor mandrake's tools have worked well for me. red carpet looks promising, but I've never been able to use it with the latest mandrake versions properly (well, it's been a while since I checked last...
Better LSB conformance, as mentioned by many here already.
Better handling of -devel packages, automatic upgrading. Oh, and better source rpm handling - better dependancies for those, and they should have an option to install the built rpm!
Options for interactive installs - where common options coudl be confirmed or changed at install itme - like debian (but preferrably only if I ask for them)