Is It Time To Change RPM?

Floris pointed us to an excellent article over at Freshmeat discussing the problems with RPM. It compares RPM to the other alternatives (mainly Debian's apt system) and discusses where the problems are. It's not a distribution war thing, this is a serious problem that needs discussing. Read the story and chime in.

Comments

The problem with RPM is uptodate documentation!

[baywulf]

In my opinion, the problem with RPM is that the documentation is falling behind. The book 'Maximum RPM' is of very good quality but it hasn't been updated since RPM 2.0 days really and so many things have changed or features have been added. For example, the relocatable packaging feature has been greatly improved. Macros and triggers have been added. The latest RPM can do automatic gzip or documentation, strip binaries and do additional checks. All this leads to RPMS of varying quality because they come from various sources, each with differing opinions and standards. If you want to see how bad it is, just use the program 'rpmlint' or a typical RPM package and see all the warnings it gives you.

Re:No one tackles the hard problems

[mosch]

ask why a new version of a package was released?
see a list of changes between old and new versions?

Well, RPM does include a Changelog which should include why the package was released, and what changes were made. check the --changelog option.

tell the system to apply only security or high-priority fixes?

You can do this mostly by installing a distro, and then tracking a particular version of it. Redhat-6.2 has lots of updates, but all of them fall into your 'security/high-priority' category.

tell the system to automatically process all updates except those involving specified packages, which I want to approve on a case-by-case basis?

It's trivial to setup something like this where you mirror the appropriate dir on updates.redhat.com, then have a script which does an rpm -F foo.rpm on every rpm whose name isn't listed in 'no-auto-upgrade.txt'. However, given your original statement, it's not possible. You're saying that you want it to automatically everything, except it should psychically know what you want to pick and choose from. Ummm... no matter how you cut it, you'll at some point have to tell the system 'upgrade or no'.

tell the system never to upgrade packages that require upgrades of packages used by other software (eg, libraries)?

This is the default behavior of RPM. You have to use --nodeps to override it.

ask for packages that will help me convert GIF files to PNG?

You want natural language capability search built into your package manager? You've watched too much star trek. If however you did a quick search for RPMs that contained both 'GIF' and 'PNG' in their name on a site like rpmfind.net you'd find gif2png is readily available.

ask for only packages targeted at beginners?

I have no idea what use this is. Beginner is a very broad term. Is Enlightenment aimed at beginners? How about Windowmaker? The answer for both is a resounding maybe!, depending on the configuration. How about gcc, is that for beginners? After all, most computer barely-literates don't know how to use a compiler. And bind, that's definitely an advanced package right? unless of course you install a caching-nameserver rpm that helps the beginner have their own caching nameserver, then it's beginner. Or an obvious beginner package like grip, whcih isn't beginner at all, i mean, you have to know about mp3 encoders and cd rippers.

ask for only well-integrated, well-tested packages?

Use RedHat, they'll only give you these. If you stick to basics, unless you use Mandrake, you usually won't get anything that's not well-tested and integrated.

get reviews of a package?

Ah yes, all programs expand until they read mail. Or in your case, you're asking for the package manager to read newsgroups and mailing lists, so it'd be a newsreader too. Maybe we should just integrate this package manager of yours into emacs.

find out how to get started using a package?

The RPM format allows for certain files to be flagged as documentation and generally installs them in the path /usr/doc/$rpm_name. and man files in /usr/man. you can get a list of what it installed by doing rpm -qi package_name.

begin browsing the documentation for a package before approving a full installation?

again, you're asking the package manager to do things that just don't make sense. Why not read up on the software, then install it? Or just install it, and if it's no use to you, do an 'rpm -e'.

have some help in configuration updates?

These are called man pages, and documentation files. You read them and they help you. Or hell, if reading real documentation is too much work for you, then see if there's a HOWTO that you can peruse somewhere on the net.

Personally I use FreeBSD which has it's own unique set of strengths and weaknesses, and if you don't think anybody out there is thinking about this stuff, you should read this document which is a summary of the state of these things in FreeBSD, and some ideas on how to progress.

----------------------------

Re:Packaging is just plain dumb

[josepha48]

Even windows does not do static linking. Windows has all those dlls that come with the packages. I am sure that Mac is probably the same. Static linking has its place, but not for everything. dll save space. If you have all static programs on your machine all programs would get to be big giant monsters that were memory hogs as well. You would not be able to dynamically load and unload dll's either. Sure you may have a faster program, but that extra speed would not be all that much to a shared object and ususally is not needed.

This is really off topic.

Now about rpm and apt-get which is what this was really about. RPM does allow you to save configs, that is whay I usually have all these .rpmsave files after I upgrade a program. I think it would be nice if there was a switch that could be passed to rpm like 'rpm -Uvh --keepconfig .rpm` to save my current configuration file without creating the rpmsave files.

rpm is not perfect. debs are not either. Last time I tried to install debain it did all its package checking at the time I selected the package rather than let me select the packages and then when I was ready to install tell me what dependancies I missed. I like rpm cause I think it was easier to learn than deb's, just my opinion though which where i am I am entitled to!

Now apt-get may work with rpms. This is good. So when does that project get started?

A second feature that would be real nice in rpm is more than just an rpm problems. It is a *nix make problem. Makefiles are not all the same. Some packages use automake and autoconf to generate the Makefile while some people just use make. Then there is really no way to know what it being installed if you are not the packager and without looking at all the sources. If I download a tar.gz and want to have an rpm out of it making that specfiles can be a real pain in the but, and half the time you can never be sure that you got all the files correctly. There has got to be a better way! If a program is in perl it may not use configure scripts it may just use a perl script. Maybe what needs to happen is a concerted effort into creatinga new system management tool. One that takes a snapshot of the system before a package is going to be insatlled and then one that takes one after. Window is doing something like this and allowing users to go back to a given point in time. So you could take a snapshot of the system before you install a program and then after you install it you can see what is changed. If rpm had this capability rpm would see what files had changed after you installed some programs ie after you do a make install or whatever. Those changes could be updated in the rpm database. If something failed the rpm database could roll the system back to before the fiels were installed. It needs some way of doing this. Maybe a program that could be turned and off at will. You could turn on the system file watcher and after you do a make install it would give you alist of fiels that have changed. It would have to be smart enough to ignore /proc of course and /tmp (or configurable to ignore certain directories) hmm ....

I don't want a lot, I just want it all!
Flame away, I have a hose!

Re:One thing I hate about RPM

[chrismcc@netus.com]

Hello...

rpm --relocate /usr/local/games/quake2=/quake2 quake.rpm

The Fundamental Mistake here

[Arker]

These guys are making a fundamental mistake. What they want is to make .rpm act like .deb. This is not going to happen in any meaningful way. .RPM and .deb are the result of fundamentally different design philosophies.

Yes, it is possible to make apt work with .rpms - but this will ONLY work satisfactorily with .rpms that are written with this in mind. The reasons given for using .rpm instead of .deb here basically boil down to there being more .rpms and more people using .rpm - but since all new .rpms will have to be produced to work with this system anyway, this is a false advantage. The installed base, the already existing library of .rpms, are going to be useless to this project in any case.

Obviously what they should do is just use .deb. The pre-existing base for .deb may be smaller than for .rpm, but it's infinitely larger than the pre-existing base of .rpms that contain the information needed to make this work, because that set doesn't exist at all.

ehhh.. maybe. but the author was in part wrong.

[hatless]

RPM's got its flaws--in particular the bloat of its cross-dependency database once a system's gone through a few big waves up upgrades. But Mr. Matsuoka--and Mr. Covey--show themselves to be surprisingly ignorant of RPM's capabilities.

What set off little bells in my head was his contention that RPM can only update files and doesn't run pre- and post-install scripts and can't prompt users for parameters and install options for the packages in question.

This is just plain wrong. An RPM can contain and run both pre- and post- scripts both during install and uninstall operations. Plenty of RPM packages containing shared libraries, for example, silently run an ldconfig after installation. RPMs of things like mysql and postgres often do a lot more--initializing a database, setting up default db users and, yes, prompting for things. If his SMTP MTA packages don't prompt for anything, that's the packager's fault. Hopefully Mr. Matsuoka's job at Connectiva isn't as lead packager for their distro.

It would be nice to see both apt and RPM adopt a rich XML-based standard for expressing prompts, defaults and so forth for interactive installers, along with a way to express what prompts can be silenced and with what effect, so that text, widget-independent GUI, and web-based (among others) interfaces to interactive installation can be built without breaking anything. But this wasn't Mr. Matsuoka's complaint. He seems to think RPM's can't be made to prompt users or execute scripts.

As for Mr. Matsuoka's other contention, that RPM needs changes in order to allow smooth auto-updating of packages, this too shows inexperience. I'm sure users of, say, Helix-Update, RedHat's Priority Update tool, and for that matter the fully-automated silent autoRPM utility would be surprised to hear RPM lacks such functionality. That he doesn't know this is kind-of-sort-of excusable, since it's not covered in the books and documentation for RPM. Not so the pre/post install script stuff. That's in the docs.

Re:ehhh.. maybe. but the author was in part wrong.

[Jason W]

The author of the article must not have made an RPM before. Every specfile generator out there has a section for pre and post install scripts. Plus, there is no reason why you can't include other commands in the middle of other sections, as is appropriate on a package-by-package basis. As you mentioned, a /lot/ of programs run ldconfig.

Configuration programs can be run also. Take the SSH RPMs for example. After installing the server RPM, it generated public and private keys. Saved me the trouble of doing it by hand, and made sure it was done right. I believe the client RPM even asked for a keyphrase. There's no explaination for what the author of the article said about not having configuration tools, except for inexperience.

I do agree that standard configuration parameters would be a nice addition, but there is absolutely no reason why package maintainers should have to conform to anything other than the stand specfile pre- and post- install sections. It allows them much more freedom and ease of use to use the scripts that come with their tar files. Why bother converting them to yet another format?

----

No one tackles the hard problems

[The Pim]

All of the package management systems duck the hard problems of creating a user-centered system management tool. Why can't I

• ask why a new version of a package was released?
• see a list of changes between old and new versions?
• tell the system to apply only security or high-priority fixes?
• tell the system to automatically process all updates except those involving specified packages, which I want to approve on a case-by-case basis?
• tell the system never to upgrade packages that require upgrades of packages used by other software (eg, libraries)?
• ask for packages that will help me convert GIF files to PNG?
• ask for only packages targeted at beginners?
• ask for only well-integrated, well-tested packages?
• get reviews of a package?
• find out how to get started using a package?
• begin browsing the documentation for a package before approving a full installation?
• have some help in configuration updates?

This is an abbreviated list, but I've wished for some variant of each many times.

Note I acknowledge that these are hard problems. I don't expect them to get implemented overnight. The problem is, I don't see anyone even trying. (Possibly Helix Code, it's too soon to be sure; at any rate, they will need the help of the distribution maintainers to go all the way.) Someone could make a great contribution by seriously studying what users need to take control of their systems and designing a solution, not just looking for the next hack.

I use Debian personally. I think dpkg+apt has more cool hacks than rpm+autorpm (or whatever), but I don't think it's significantly further in the big picture. I do think it has more possibilities, given its philosophy and development community.

Finally, I know some moron will jump up saying that rpm wasn't meant to do all this, and its developers intentionally limit its scope. I don't care whether rpm solves the problem, or a system build around rpm solves it; I do care that the problem isn't being addressed.

I wish I could do this myself, but...

[dbarclay10]

I wish I had more time to learn how to program, and then actually program something. Many of you will be familiar with GNU Stow, and maybe even some of you had tried it. Well, I have. It's pretty nasty. While it works, it is cumbersome. But, I strongly think they've got the right idea.

For those of you not familiar with GNU Stow, it allows you to install a program in an arbitrary subdirectory(say, /usr/local/stow/Quake2-version), and then it makes symbolic links, recursively, from the installation directory to the system directories. ie: /usr/local/stow/Quake2-version/bin/quake2 is linked to /usr/bin/quake2.

I really think that's an incredibly good thing. For many reasons, and let me elaborate.

If you're at an unfamiliar system, or you're using a rescue disk, you might not know of, or have access to a package manager. You can't add nor delete packages, and you can't query packages. You don't know what files a package contains, and you don't know to which package a file belongs. I feel it's imperative that you can accomplish all of those tasks with standard *NIX utilities(ie: ls, mv, cp, ln, rm, cat, etc., etc.). To see what files are contained in the aforementioned Quake II package, I'd just need to do a 'ls -R /usr/local/stow/Quake2-version'. To see what what package owned /usr/bin/quake2, I'd just need to do 'ls -l /usr/bin/quake2'.

Of course, a good symbolic-link-based package manager should be a bit more complete. Now, RPM(I don't know about APT) uses a database to store its information. I gotta say, that's pretty stupid(no offense, RPM guys - I'm sure you have good reasons). At least, it's not very robust, from a system recovery/stability standpoint. So we want to get rid of a database. After all, we want to be able to manage packages with standard *NIX utilities, if we're really stuck in a bind. So, I guess each package would have some files, in its installation root(ie: /usr/local/stow/Quake2-version/), describing some things. Files named things like Requirements, Provisions, PackageInfo, PackageConfig.

Requirements - Would have sections on both file-dependancies(ie: /bin/ls) if the package required individual files, and package-dependancies(ie: fileutils-4.0).
Provisions - Would have sections on libraries and possibly a seciton on packages which the installed package replaces(ie: Postfix replaces sendmail).
PackageInfo - Would have a description of the package, and some notes on how the particular package may differ from the standard source distribution. Also some user-friendliness things like the type of software(ie: System -> Libraries) and such.
PackageConfig - This would contain the pre- and post-install scripts(yes, we really want to know what a package does!), and maybe anything that was done during installation based on any input the user gave.

These are just ideas, and I don't have the skills or time to implement them, so don't take it to heart too much ;) To be honest, I don't think any new package management system will succeed unless it has compatibility layers for RPM and APT. Both on the shared-library leve, and on the command-line level.

'Round the firewall,
Out the modem,
Through the router,
Down the wire,

linux-ports?

[Arandir]

The small amount of time that I have been with FreeBSD, I am amazed at the power and flexibility of the ports system.Sure there's a few rough spots, but those are easy enough to polish out.

For those that don't know, where the synopsis: the ports system is a collectin of makefiles and diffs to properly fetch, extract, configure, build, install and register a software package for the target system. A FreeBSD package is simply a port that has been precompiled, so you don't have to be afraid of typing "make" at the commandline. And these packages have utility programs along with them, like pkg_add, pkg_remove, pkg_info, etc. Dependencies are kept track of, including checking for individual libraries instead of monolithic packages. Very similar to Debian's method.

So how does this fit into the Linux continuum? Well, right now there is a concerted effort to make a unified BSD ports system, instead of separate ones for each *BSD. There is no reason that Linux could not get involved so that there will be a linux-ports variant. Hell, there's no reason that it couldn't be a grand unified UNIX-PORTS! And there's no reason that deb and rpm packages can't be fit into the system as well. I keep hearing rumours that Slackware will go to a ports-style system, and I hope they do.

If you're a potato or hamm head, and have always criticized the ports because it didn't have some minor feature, now is the time to get involved.