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.
is fine, if the pkg is of enough "signifigance" to be included.
otherwise...
# rpm -ivh foo.rpm
works for me... most of the time.
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.
Something as important as a package manager can't be this buggy.
Joe
http://www.joegrossberg.com
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).
-- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
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.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
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.
I value a package manager that uses a decent naming convention for its packages. If I want to install ncurses, I want to type install ncurses, not install libncurses5.
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.
This space intentionally left blank.
0x0d0a writes
Hah! 0x0d0a = 3338 = 666 * 5 + 8
You, sir, are the DEVIL IN DISGUISE!
except for one thing. The size of the control files. I'm on a modem(no broadband avail) and for some reason i decided to go debian/testing. Waiting for that thing to download a 2MB file, and then tell me there are no updates pertaining to my system is really a killjoy. ... but .. thats just me
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
Well, I prefer Fedex for my packages... UPS sucks and priority mail is too slow.
Repeal the DMCA!
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.
Many may not have had the pleasure of using uPM yet. It is a new package manager that seems to be very well thought out and seems to be heavily bassed on dpkg and ebuild/emerge. It represents the best features of both. It aims to simplify the build process and allow for binary packages to be built from the customized build process.
I would look for uOS, 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.
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.
Programming can be fun again. Film at 11.
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...
May we never see th
RPMs never seemd to work across distros, quel suprise. This is one thing that I really like about slackware's .tgz files.
./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.
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
May we never see th
When I install a package, I want it to create all the icons and folders on the desktop and launch bar. And I want it to detect my window manager and adjust accordingly.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Why can't we have source tarballs that resolve dependencies?
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.
I really like slackware's approach...my only issue with it has been that it doesn't clean up after itself on an upgrade very well...
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.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
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
You could just use Gentoo like the rest of us. :)
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
Provide just enough extra code in the graphical package manager to run in 640x480x16 VGA mode.
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.
-=-=-=-=- osjedi uses Debian GNU/Linux. -=-=-=-=-
The thing that I like most about many Windows-based installers (these days) is the ability to step through the package install options and accept default values and have the package be installed in ready-to-run state.
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.
...try using the "synaptic" front end from connectiva web page or google around for some other places. Great apt4rpm front end gui tool.
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.
What's wrong with the System V package management tools?
...
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
One suggestion I'd add to this is making a *single* screen with all the config options on it, so that the user isn't going click, click, click, click through a series of dialog boxes.
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.
May we never see th
I'd like to see front ends be a bit better.
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.)
Here are some features that would be good.
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.
Beside many other things already mentioned I need a good auto/online update. Current SuSE allows me to keep all my packages up to date by 3-some clicks! I just don't have the time to keep up to date with all the security issues arising around the packages I have installed. If SuSE takes care about this I can perfectly live with it; installing their distro already means trusting them...
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).
RFC1925
Many package management systems seem to implicitly assume that a system is connected to update servers through a broadband connection. Many people are connected through a piddly modem, but have a broadband connection at work/school.
I would love to be able to tell my system to dump my package database to CD. Then I could cart the CD to school, have the school computer look at the file, download new packages to CD, and walk home and install them.
I want a small-band apt-get!!
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)
[Science] is one of the very few things that raises human life a little above farce and gives it the grace of tragedy.