Is it time to change RPM?
 by Claudio Matsuoka, in Editorials - Sat, Sep 16th 2000 23:59 PDT

New Linux distributions usually base their package management on one of two options -- Red Hat's or Debian's. Brazilian distributor Conectiva decided to go with RPM, but has reservations about its ability to provide smooth automated upgrades. In today's editorial, Conectiva's Claudio Matsuoka describes the problems he sees and what he thinks should be done.

The scenario

In the past few years, changes in the Linux world helped the operating system gain acceptance in the mainstream market. Package management has played no small role in this process. Thanks to dependency checking, the overall system consistency is kept. Thanks to file databases, removal of unneeded software is as easy as installing new, up-to-date precompiled binaries that are guaranteed to work on your system. Sysadmin skills are not a prerequisite to run Linux anymore; C and makefile knowledge are no longer required. RPM and Debian packages ruled the world, the first adopted by the vast majority of commercial Linux distributions. In a quick glance, the two systems are just two implementations of the same idea, with no major differences. A few details, however, make a big difference in the auto-updating process.

We first met automatic package retrieval and installation in the form of apt-get. Debian users are glad to have such a wonderful tool. One step ahead of package management, users can now keep all their packages up-to-date, and add/remove packages tied to an intricate dependency graph, by issuing a single command. And, even better, APT was designed to be system-agnostic, so no matter if you use .debs or .rpms; we'll all be happy.

Well, not quite. Mixing APT and RPM is an obvious step in making users of RPM-based distributions happier, and probably every vendor has considered implementing it. A few design problems, however, have made this goal not so easy to accomplish, and many distributions decided to use their own updating system. This is not a very good situation; it fragments the user (and potential developer) base, it may create incompatibilities, and it duplicates development effort. On the other hand, apt-get is ready, has proven to be reliable, and has a nice set of companion utilities such as apt-cache, apt-move, apt-zip, and gnome-apt.

The problem

Just like a painter who paints the floor of a room and gets trapped in a corner, certain features in RPM seem to have been designed to make integration with APT impossible (which makes a lot of sense if you consider that RPM is older than APT). File dependencies, for instance, make your reverse dependency database grow to insane proportions, and the existence of packages optimized for different processors on the same architecture doesn't help. But that's not the problem. Thanks to the efforts of Alfredo Kojima of WindowMaker fame, now working at RPM-based distributor Conectiva [Ed: Conectiva is also Mr. Matsuoka's employer], most technical issues have been quickly addressed and, despite claims that it couldn't be done, it actually works. So is updating RPMs now as simple as updating Debian packages?

Yes and no. Yes, you can install, remove, and update packages in a painless process with all dependencies resolved. No, it's not the same thing. RPM packages can't be configured interactively. They won't ask you if you want to keep the current version of a configuration file, install a new version, or compare the two versions. They won't stop services before updating and restart them afterwards. The MTA won't ask you a few questions and configure itself. They won't even issue a warning to the administrator. We need to walk one more step to have it work properly.

The solution

First of all, it would be a valuable addition to RPM to provide some mechanism to configure all unpacked but unconfigured packages. Pre- and post-install scripts, as well as pre- and post-removal scripts, should be executed appropriately to allow smooth upgrading of running services. Package maintainers would have to add such scripts to their packages and make sure they'll not break the system the package is being installed on, keeping in mind the diversity of RPM-based distributions out there. Auditing, predependencies, package flags, and auto-deconfiguration functionality must be implemented. Small details like "obsoletes" with version numbers should also be provided, and package priorities -- at least "essential" marked packages -- are a nice thing to have.

Most of the effort required by such a change would be in the packaging policy. A few issues still remain unsolved, most notably how to handle multiple versions of the same package installed on the system and what to do with packages with the same name but different vendors.

The future

Indeed, the above description matches the current features of Debian packages. But all these features, regardless of what packaging system they come from, are important to making auto-updating easy, reliable, and not likely to stop your system due to misconfiguration, removal of an essential component, or even security holes introduced by mismatched configuration files. "So what's the point," you may ask, "of implementing something that's already there, just under a different name?" A few issues must be considered:

• RPM has a huge install base and is widely supported by many vendors and developers. Switching is not cost-effective. RPM is one of the major standards (the other being .deb), and you can't simply drop it.
• RPM has a big acceptance among users and developers. Forcing them to change is not possible or desirable.
• The changes required to have a smoother integration with apt-get are mostly in the packaging policy; the changes needed in the tool itself are not great.
• Buildmasters and packaging people like file dependencies and consider them a Good Thing(tm).
• RPM has features not available in .deb, such as the ability to keep different versions of the same package installed as long as they don't overlap in the filesystem.
• RPM may be adopted as an LSB standard.

Is it time to change RPM to allow smoother auto-updating? Will it be the start of a road for .rpm and .deb interoperability, or will it lead us in the opposite direction, restricting the installation of software packages to the ones specifically designed for your RPM-based distribution? Should the LSB be concerned about these issues? What role will be played by auto-rpm, up2date, and other auto-updating tools? Or shall we leave things as they are, and declare that full apt-get functionality is an unneeded feature?

Claudio Matsuoka (claudio@dexter.damec.cefetpr.br)

is striving to finish his dissertation on robot dynamics simulation and receive his M.Sc. degree in Industrial Computer Science.

Claudio Matsuoka (claudio@helllabs.org)

maintains a few free software packages, including the xmp mod player.

Claudio Matsuoka (claudio@conectiva.com)

works at Linux distributor Conectiva doing miscellaneous hacks, including work on the V4L, Colour Quickcam, and OV511 kernel drivers. He keeps a diary at Advogato.

T-Shirts and Fame!

[Comments are disabled]

Referenced categories Topic :: System :: Archiving :: Packaging Topic :: System :: Software Distribution Topic :: System :: Software Distribution Tools

Referenced projects AutoRPM - An RPM auto-installer and/or FTP mirrorer. Debian GNU/Linux - The Universal Operating System. dpkg - A package maintenance system for Debian GNU/Linux. RPM - The RPM package management system.

 Comments

[»] apt-get is a solution... but not for experienced users
by Frédéric L. W. Meunier - Oct 29th 2000 06:34:26

You can make the best advanced InstallShield(tm), but I'm one of those that'd never trust binaries from third parties, aside those shipped with my distribution. What I see is that apt-get (at least the one shipped with Debian) is doing basically what the Windows users always wanted, facility without security in mind. I don't agree that "it is well known that building from source is no better than installing pre-built binaries unless you carefully audit every piece of code you compile". I'm still someone that likes to do the job. I've heard a lot of complaints from people using apt-get, especially when they upgraded packages and things stopped working (should I mention upgrading libraries?). But apt-get accepted to install such applications. I played with RedHat for 2 years and never enjoyed their package manager. I never played with Debian because I don't like their package manager and ideals, despite it being "GNU/Linux". I wanted simplicity, and I found Slackware. If you're an experienced user and want a package manager, then use what fits your needs, but make your own packages.

[reply] [top]

[»] Re: apt-get is a solution... but not for experienced users
by Eduardo Linux - Mar 18th 2001 03:52:00

Choose version: English
Escolha versão: Português

You guys should know that Debian has the very best (un)installing system of all of them. All of us know that rpm is defective, and try to make it |compatible| with deb may sound like a utopic dream. Well, dreams are the main fuel of several things, but i still guess that a dual database system is the best option...
Honestly, I don't know... deb is very good to rpm, but I hope Claudio can do a very well job.

Todos vocês devem saber que o Debian tem o melhor sistema de (des)instalação de todas as distros. Todos nós sabemos que o rpm é defeituoso, e tentar torná-lo |compatível| com o deb pode parecer um sonho utópico. Bem, sonhos são o combustível principal de várias coisas, mas ainda acho que uma base de dados dupla é a melhor solução.
Sinceramente, eu não sei... O deb é muito bom pro rpm, mas espero que o Cláudio possa fazer um bom trabalho.

--
Winners don't use drugs. Use Linux...

[reply] [top]

---

[»] Current RPM+apt status
by Claudio Matsuoka - Oct 28th 2000 16:44:27

This is what it already does:

[root@pokey:/root] apt-get update
Hit http://zaphod.distro.conectiva latest/conectiva/base/pkglist.001
Ign http://zaphod.distro.conectiva latest/conectiva release
Get:1 ftp://mapi2.distro.conectiva 5.9/conectiva/base/pkglist.001 [186kB]
Get:2 ftp://mapi2.distro.conectiva 5.9/conectiva release
Ign ftp://mapi2.distro.conectiva 5.9/conectiva release
Get:3 ftp://mapi2.distro.conectiva 5.9/conectiva/base/pkglist.002
[86.7kB]
Fetched 273kB in 4s (58.3kB/s)                                    
Processing File Dependencies... Done
Reading Package Lists... Done       
Building Dependency Tree... Done

[root@pokey:/root] apt-get install pingus
Processing File Dependencies... Done
Reading Package Lists... Done       
Building Dependency Tree... Done
The following extra packages will be installed:
  ClanLib Hermes 
The following NEW packages will be installed:
  ClanLib Hermes pingus 
0 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/1561kB of archives. After unpacking 6198kB will be used.
Do you want to continue? [Y/n] 
Executing RPM (-Uvh)...
Preparing...                ###########################################
[100%]
   1:pingus                 ########################################### [
33%]
   2:ClanLib                ########################################### [
66%]
   3:Hermes                 ###########################################
[100%]

[root@pokey:/root] apt-get remove Hermes 
Processing File Dependencies... Done
Reading Package Lists... Done       
Building Dependency Tree... Done
The following packages will be REMOVED:
  ClanLib Hermes pingus 
0 packages upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
Need to get 0B of archives. After unpacking 6198kB will be freed.
Do you want to continue? [Y/n] 
Executing RPM (-e)...
cannot remove /usr/share/games/pingus - directory not empty
[root@pokey:/root] 

Also we need a better (faster, smarter, more reliable) dependency check, either to see the which packages must go in the same transaction when installing with rpm -Uvh, or to allow apt itself to reliably resolve all the stuff (currently it asks rpmlib, and it returns some faulty answers :/ -- bad rpmlib!) and install using --force --nodeps. Otherwise, all packages being installed must go in a single transaction, hugely slowing down the process if a large number ( > 300) of packages is going to be installed.

[reply] [top]

[»] RPM vis-a-vis APT-GET
by Scott G - Oct 28th 2000 13:21:16

I've been running RedHat at work and at home for more than two years (though I have 12 years of Unix sysadmin experience in all flavors, including UNICOS...).

The most important requirements for me for any packaging system:

• Automatic installation
• Interactive config when needed
• Automatic handling of dependencies

I just switched over to Debian at home, and what a dream apt-get is! I will probably never go back to RedHat or any other RPM-based OS. I'll be switching over the systems at work in a couple of weeks.

My suggestions:

• Merge RPM and Debian
• All vendors adhere to File System Standard

[reply] [top]

[»] New features in APT
by Claudio Matsuoka - Sep 23rd 2000 14:09:30

Regarding some features requested by a Slashdot reader and listed in a previous comment: the "version pinning" feature is already in the apt CVS repository, as published in Debian Weekly News. Also Jason Gunthorpe has a proposal for package urgency:

Now that APT has a pinning mechanism it would be very nice if you could automatically install higher urgency upgrades and leave low priority stuff behind. ( ... ) The idea we struck on was for each package to have a 'urgency serial number' which exists on the ring [0...N]. The difference in the priority serial numbers of any two packages indicates how urgent the upgrade is.

About Antonio Marcelo's comment above, it is well known that building from source is no better than installing pre-built binaries unless you carefully audit every piece of code you compile, and few users consider auditing code a real pleasure.

[reply] [top]

[»] Following the Microsoft Steps ?
by Antonio Marcelo - Sep 19th 2000 11:26:35

Friends,

The entire discussion is about the rpm, the famous package tool for the Red Hat Linux and your clones (like Conectiva in Brasil). In my poor opinion one thing is very important : inteligence.
For new users in Linux is very important a tool for easy instalation of the major aplications, but for the experienced user many questions :

a) Where this package is locate ?
b) What the libs, bins or other things "enters" in my system ?
c) Well how works the uninstall process ? Just type a one command line ?

It´s smell Microsoft´s idea : Don´t think, we think four you !

Well the defender´s of rpm and other packages says : your questions are to easy to answer. Look this type this command, or use F3 in Midnight Commander.

I´m working with Linux security and in my opinion pre-compiled binaries is to dangerous for any server in web. The idea of rpm is very good for workstations (with many considerations and restrictions...) behind a firewall and other security goodies. A rpm package can contain a trojaned version of one software or a great buffer overflow in the code. In any case the problem is the old paradigm of the Microsoft´s "Black Box Code".

Well my idea of packager or other thing are scripts, or installers of the gnu softwares, with the options like "Custom Setup" or "Automatic Setup", with the source code for avaliation or free options for thr easy compile with security libs (like Libsafe). This idea is very simple to implement and our team of developer´s began to work in this philosophie.

But the idea of pre compiled binaries in easy packager scary me. In our work rpm´s and other stuff´s was banned, and we use only the old tarball.

This is my opinion, and sorry for my poor English.

Antonio Marcelo
Security Specialist
Bufferoverflow.org - Brasil

[reply] [top]

[»] Mail feedback & a few more comments
by Claudio Matsuoka - Sep 19th 2000 09:33:35

I've received some email feedback and I'd like to share some of the comments with the readers interested in the subject:

• Red Hat's Matt Wilson points that Red Hat 7.0 includes the ability to stop and start services on package upgrade. This is certainly a step in the right direction, as long as you can ensure that the services are restarted with proper configuration.

• WhatifLinux provides a commercial service the checks dependencies and monitors packages for updates in RPM-based systems.

In slashdot, Arker says that "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." This is similar to Nate's comment above, saying that "yes, we can just drop [RPM]" and daevt's point on "all pipes were once made of lead". Vasilis is also for .deb, arguing that "changes will be needed anyway, so why not just make this big change once and for all?" Hash compares RPM's ubiquity to Windows.

(It's also worth of mention that cesarcardoso discovered that Conectiva is against open standards and GPL. It should be obvious by now, that's why Conectiva is now creating the proprietary, closed-source apt-get instead of a open, free and pre-existing solution.)

What do I have to say? In my personal opinion, and you may agree or not, dpkg currently offers a technically superior solution to package management than rpm 3 (as I'm more a developer guy and not a packager, I still don't know what goodies RPM 4 has to offer. Shame on me.) Switching in midstream, however, is costly and dangerous. It would require repackaging effort, re-structuration effort, testing effort and lots, lots of learning. Conectiva, and all other RPM-based distributors, structured themselves around RPM. Besides packaging itself, there's the support for current and previous releases, printed documentation, release upgrades. training, building and testing scripts, policies -- the lead pipe switch wasn't made in a week, a year or ten years. You can't mix .rpm and .deb packages in a single release and expect it to work, while mixing fully apt-compliant RPM packages with partially-compliant packages is more acceptable, and package conversion to the new standards would be faster and smoother than a switch to .deb. Also Conectiva's packaging team isn't large (it can be fit entirely in a small hoghouse -- this is an internal joke) and the two buildmasters worked on RPM for a long time to acquire the RPM expertise needed to put together a distribution. Remember that every commercial Linux distributor (at least those in Real World) work with limited budget and tight release schedules.

And, of course, the solution demanded by Cyberai for eight-level dependency resolution already exists, and it's called apt-get.

[reply] [top]

[»] RPM dependencies
by jpileborg - Sep 19th 2000 04:16:39

I think that RPM is a nice and easy way of installing/removing packages, except when it comes to
dependencies. Instead of just checking require/provide names in a database, a mechanism more like
AC_CHECK_LIB and AC_CHECK_PROGRAM from autoconf. I should be able to say 'I need this-and-that
library, version 2.5 or higher', or 'I need program x-and-y, version 1.7 up to 1.9'. Also, many packages
today comes with a shell-script names packagename-config, which supplies compilation and link flags
that users of that package needs, and also the package version. An attempt to standardize the use of
such a shell-script should be encouraged.

Well well, just my thoughts.

/ Joachim

[reply] [top]

[»] Experiences with different distributions.
by hash - Sep 18th 2000 21:23:42

It seems from most of the posts above that people have serious problems with the way RPM handles dependencies, and even though in theory it is meant to enable automated unattended package installation, it does such a poor job of it that most anybody who's used dselect, dpkg and apt-get is amazed at how smoothly and painlessly they get the job done, even if one has to answer a few questions to get the packages configured right.

This certainly bears out my own experience. I switched from Slackware to RH 4.0 when that came out, and in a very short time was thoroughly fed up with the mess RPM made of my systems. It often got to a point where the dependencies and package state databases were so totally fubared that a complete re-install was needed to get the system back into some sort of stable state. It was completely horrifying trying to run a production server with this kind of mess.

Trying to find a way out, I experimented with SuSE and though the colorful install program looked very spiffy, I was disgusted by how windoze-ish it made everything on my test box. I couldn't even edit /etc/hosts and expect the changes to be effective. Everything had to be done either through YaST or by tweaking a single centralized config file which superceded all the standard config files... it was bizarre and I haven't yet fully recovered from that claustrophobic experience. It was just like being stuck in Windoze-land. I suppose some people like it that way, but I just couldn't handle it.

Then I installed Debian on the test box and haven't looked back since. Debian gives me the feel of an open, powerful and tweakable installation like none of the other distributions. Before I started using Debian, I'd almost been converted over by a friend to the view that expecting any package management system to handle the complexities of maintaining an evolving installation was simple-minded, and that the way to go was to hand-hack everything and know exactly what went where on your system.

(This friend had been running a Slackware distro I'd downloaded in '94 on a 1200 BPS modem, and he'd just kept upgrading the system by hand-grafting bits and pieces in over the years. He'd actually managed to go all the way from a pre-ELF kernel 0.99pl9 system to having glibc and Enlightnment running on this mongrel box before he finally gave in and installed a new RH distro.)

I tried that sort of thing on a remote production server for a while and it was a complete disaster. I fared slightly better with a similar strategy on my laptop. When I upgraded, I'd install a whole new distro on a new partition without destroying the old install, and then I'd boot the new system, mount the old system on /mnt/old, and spend the next six months running some stuff off the new install and some stuff chrooted into the old environment, until I got everything migrated over to the new install, by which time it was time once again to replace the distro (or the laptop).

This wouldn't work for production servers of-course, and I finally got around to trying Debian. Within a few days I was hooked. Everything was manageable once again and I could install most packages quickly and painlessly without hunting all over the net for packages to satisfy dependencies. I could quickly secure my servers using the non-us sources, and easily replicate them with dpkg --get-selections and --set-selections. Things were looking up.

Then I found instmon, a simple script that detects changes on a system and builds deb packages out of them, greatly easing the task of importing new stuff into my installations, and was pretty much all set. I've been maintaining a number of machines using the Debian tools for a while, and I've never found it so painless. Debian frees up my time for more important stuff and gives me more power to do what I want with my systems with less bureaucratic overhead than any other distribution I've used.

There's only two things I have on my wish list now, and they're not hard to do:

1. I'd like to have the ability to browse external package archives from dselect without merging their packages info into the local packages database. Something similar to the way GNUS lets me browse external news sources without integrating all their active groups into my newsrc. This would be great, for example, to pick up the latest version of a single package from the 'unstable' tree without forcing my whole system to switch to the unstable distribution.

2. It'd be great to have a simple instmon-like wrapper around the CPAN shell so when I install new perl modules off CPAN, they automatically get debianized on install and added to the local packages database. This would really not take much to whip up at all and I'll probably do it some lazy Sunday afternoon.

All in all, after using and reviewing a whole bunch of different distributions, I found Debian way ahead of the others in usability and maintainability, and consider the popularity of RH/RPM based distros to be oppressively like the popularity of Windoze:

> RPM has a huge install base and is widely supported by many 
> vendors and developers. Switching is not cost-effective. RPM is 
> one of the major standards (the other being .deb), and you can't 
> simply drop it.

< Windows has a huge install base and is widely supported by many
< vendors and developers. Switching is not cost-effective. Windows
< is one of the major standards (the other being MacOS / Linux /
< whatever), and you can't simply drop it.

> RPM has a big acceptance among users and developers. Forcing 
> them to change is not possible or desirable.

< Windows has a big acceptance among users and developers. 
< Forcing them to change is not possible or desirable.

The attitude of many vendors providing Linux-related services adds force to this analogy. Recently a client signed up for a server with DellHost. When I wanted to replace the default RH install with Debian, I asked the tech support staff if there were any special hardware considerations I should be aware of. It looked to me like they had some wierd ethernet interfaces in the box.

The tech support people sent me a number of (HTML formatted) mails to the effect that a) RH was the only supported distribution, b) they would not allow me to install Debian on the server (which my client had paid for), c) if I tried to install Debian I would not succeed and they would charge me $100 per hour to re-install RH, and d) even if I did succeed in installing the distribution of my choice on a server owned by my client, they would refuse to support it. I said to hell with you and went ahead and put Debian on the box without any trouble.

Three days later we had a flurry of mails from the tech support staff informing us that we had cut off their back-door 'maintenance port' access to our box and that if we didn't enable it again they would have to reboot the box into single user mode and get root themselves. All this 'for our own good', of-course, since we couldn't possibly be trusted to run our own systems the way we wanted.

Unfortunately, RH seems to have become the Windoze of the GNU/Linux landscape, and this is most evident in the blind adherence to and popularity of RPM packages and RH style distros despite their obvious technical shortcomings in comparison to the alternatives available. I'm waiting for VA to start pre-installing and supporting Debian before I'll buy a box from them. I hope they read FM comments.

Hash

[reply] [top]

[»] You guys are great!
by Steven Wagner - Sep 18th 2000 16:52:16

I love open source! I've never seen so many well thought out points. I never thought of all these possibilities with package management. This is truly a perfect example of the open source process.

[reply] [top]

[»] Feedback from Slashdot
by Claudio Matsuoka - Sep 18th 2000 11:27:49

This article has been linked from Slashdot, and some interestiong points have been raised there as well. Here are a few, for those who don't want to browse through the whole list of comments:

• Arker writes: "Well we aren't talking about RedHat here (...) -- they designed RPM for the needs of the market they are going after, and it servest them fairly well) but Conectiva - a very different distribution designed for a different market. It is Conectiva that desires the apt functionality - RedHat does not. And yes, it would be a pain to switch over in midstream, but it would be equally a pain to try and hack RPM into doing things that it's designers consciously eschewed (...)" But certainly a change in RPM would benefit all distributions based on the format, and would avoid a fork in the project.

• hatless writes: "(...) 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. (...) As for Mr. Matsuoka's other contention, that RPM needs changes in order to allow smooth auto-updating of packages, this too shows inexperience.", and Jason W adds: The author of the article must not have made an RPM before.". There are problems in upgrading that are quite subtle and won't show themselves until you actually try to run apt-get with rpm. These are described in the article and in Jason Gunthorpe 's comment above. Also in slashdot, mrsam clarifies: "The thing is that RPM packages **cannot** have interactive install/uninstall scripts. Well, sure, you can create one of these things, however all you could do with them is use them yourself. All RPM packages shipped by redhat or any distributor (AFAIK) are **designed** to be noninteractive, so that the vendor's installer can load them up as part of a nice graphical installation script."

• From SomeOtherGuy: "Would not it scare the RPM based distros to go with DEB, when it would be easier to only install a distribution 1 time. I mean their has to be something to the fact that each time I walk into Best Buy or Comp-usa, I notice a new point release of Redhat, Mandrake, Caldera, or Suse...I think apt-get update;apt-get dist-upgrade would just rain on that parade." The question is answered by Dionysus: "considering the fact that RedHat and the commercial distributions business model is not to make money on the CD but rather the services, it shouldn't matter much."

• Some of The Pim's ideas are woth to mention:
  • Tell the system to apply only security or high-priority fixes. This can be done with apt-get, if the distributor places security and high-priority updates in a component or server of its own and tell apt-get to only retrieve packages from there.
  • Tell the system to automatically process all updates except those involving specified packages, which I want to approve on a case-by-case basis. This would be great, and AFAIK there's no support for such functionality in apt + dpkg.
  • Ask for packages that will help me convert GIF files to PNG? This can be done (if you use the appropriate queries) with "apt-cache search".
  • Ask for only well-integrated, well-tested packages? In Debian those go in "stable".

• Anonymous Coward says: So, depite the configuration flaws described in the article, apt-get's dependency resolution and package retrieval is already working for RPMs, so even those who dismiss interactive configuration as a completely useless feature will still be able to upgrade their RPM-based systems using apt-get. Yes indeed, this is the case.

• grytpype says: "The rpmfind database seems to have all the necessary information, why doesn't someone just write a wrapper? Well, many reasons. One of them is that you would need to be connected in order to use the system -- apt-get can retrieve from local filesystems or private repositories. And doing as described would not ensure that the packages would work after installation, since packages are fetched from different sources and may be not properly integrated (yes, this happens in real world).

• And finally, jetson123 claims that "I don't see anything that can be done with Debian packages that can't be done easily with RPM." Deferred configuration is one of them.

[reply] [top]

[»] RE: It's time to stop talking RPM/Deb and talk about REAL installers
by Gregory R. Warnes - Sep 18th 2000 10:53:29

The dependency problem you describe doesn't happen using the debian tools. When you choose a package to install, all of the dependencies are resolved and all of the packages get downloaded and installed . Essentially, the tool does the 8 level dependency tree for you.

[reply] [top]

[»] It's time to stop talking RPM/Deb and talk about REAL installers
by Cyberai - Sep 18th 2000 09:45:24

In reading this article and the folow up comments, I am struck by one central thought. Everyone here, including the author of this article have missed the point! The author comes closest by at least aticulating that the RPM/Deb methods (and the others mentioned) are really pretty poor installers when you get right down to it. When I entered into the Linux world, I began by installing RedHat and then trying to install a few programs. I was absolutely horrified by my first experience. After downloading and running the RPM, I was informed I was missing a few dependancies. When I found those, I discovered that they required yet MORE dependancies. In the end, I wound up having to make a CHART just to map it all out and make sure I had everything. I had to go 8 layers deep! I installed over 27 things and had to compile most of them! It took me over 6 hours to download and install a simple email program with a graphical interface. How pathertic is that? I am sorry, but this proves to me that Linux is NOT ready for the big time. I am running it alongside my Mac and using it more and more. But I can tell you that I am probably a member of the 1% who would put up with the difficulties in order to use it. I have learned how to makefile in order to survive, but would your mother? In order for Linux to graduate from the basement of the computer world and come out into the sun, a REAL installer needs to be created. One that has enough brains to install the dependancies it needs (including dependancies of dependancies!), stop the processes it is updating and restart them afterwards. It should also be able to UN-install what it just put in and restore the system to its previous state should the user ask it to. These are functions that have been standard on Macs for over ten years! WinX was not far behind. Considering the amount of brain power and talent in the Linux community, I am stunned this hasnt happened yet. This isnt rocket science people, it's simple logic. We all want Linux to grow and take a byte out of the corporate OS market. I want it more than most. But unless we in the community wake up and remove our craniums from our posteriors it won't happen. We need to be looking at those features of the commercial OS's that attract user base and reproduce them, heck even improve them! I know we can do it, look at what we have accomplished so far! But I am afraid that it is too fragmented to be fixed now. The very fact that no one has brought up the points I have frightens me. We are rearranging the deck chairs on the Titanic. We spend time bickering over how to change RPM or Deb, when its time to trash them! I think the solution will come, but not from us. Apple computer will probably make us all look like idiots. They will create a simple unified way to install applications with all the features of modern installers on it's "BSD-like" OSX. I understand that the process is almost complete. I recently installed SUN's office suite and they actually did it right. I never had to leave the installer once to get a ".so" or library of any kind. It just installed and worked. I know a lot of you are thinking right now that my opinion is just another whiny Mac/Windows user wanting Linux to be more idiot proof. I have encountered "Linux elitism" a lot since I have gotten into this. But you need to realize that the opinion of people like me will determine the future of Linux, not yours. We want the things Linux can give us (low cost, open development, power, stability). We will get them from whoever delivers it. Sooner or later a corporation will figure out that they can make a lot of money by delivering this to us. We better wake up and lead, or the big corporations will. Cyb.

[reply] [top]

[»] View from a longtime RedHat user who switched to Debian
by quinticent - Sep 18th 2000 09:21:06

Debian isn't the perfect system. In fact, there are some things I can do easier in RedHat than I can do on a Debian System but I suspect that this is because a majority of people develop on and for RedHat. One thing though that stands out between the two is their packaging system. It is my opinion (I don't want to relate this as fact as so many people erronosly do) that .deb's are so much cleaner than rpms. Upon installing RedHat everything works great out of the box but as always seems happens in a box where packages are constantly being installed, updated and removed, my system starts to act funky. Things won't install, libraries won't link, ect. Debian on the other hand is a model in consitancy and stability. Every time I go to compile a program I have been working on and I need something installed on my system I simply apt-get install it. Everything is put in its proper place and the system works without so much as a hiccup and my config files are handled quite nicely (unlike RPM). This was the reason I switched. I was tired of coming back to school and having to completely reinstall Linux because RedHat 6.1 can't cleanly upgrade to 6.2 (and you can forget about 5.2 to 6.0). Debian's install is based on apt-get and .debs and even has a program to update the whole distributions keeping the dependencies in check. Now if they can cleanly integrate apt-get with RPM I will gladly switch back (I like the config tool chain better on RedHat - oh no watch out for the flames) but until it is done cleanly w/ RPM I'm gona to stick with Debian based distro.

-Quinticent

[reply] [top]

[»] not just a packaging problem...
by Luca Andreucci - Sep 18th 2000 09:10:47

In my opinion, we're not just suffering from packaging system incompatibility problems. There are other, probably much bigger issues.

There are filesystem/init/administration incompatibilities between GNU/Linux distros. Expert Linux users can live with this, but I'm not sure how much it is desirable.

There are major security issues -- yes, I know that package managers have features addressing these, but look around and see. Are we all waiting for something BAD to happen, just to lose the face and start doing something about it?

The whole Un*x way of disposing/managing binaries and libraries is weird and (methinks) not up to the task.

I believe we should look into something that is more up-to-date. I recently had a chance to take a (not so) close look at Mac OS X way of handling binaries and libraries (the so-called "bundles" -- I think the tech comes straight from NeXT) and I believe the guys are way ahead.

Is there anyone interested in discussing if/how implementing something of the kind on GNU/Linux would be possible?

--
mail $(echo bmFxZXJqQG5hcWVyai5iZXQK | base64 -d | rot13) http://3273647156/andrew/

[reply] [top]

[»] Debian tricks
by Colin Watson - Sep 18th 2000 06:44:45

Deb is not perfect either. Since RPM dominates the user base (hey, there's way more people using rpms than debs), maintaining packages is harder as there's not as much hands to put things together. I found myself getting licq-0.76 while the latest is 0.85.

You might want to use unstable (woody) if you often have problems like this. 0.85 is in unstable, and I'm using it happily.

One feature (If there's one, tell me please!) that I would like to see in rpm and deb is that the admin could tell rpm and deb that a tarball is installed; therefore maintaining the dependencies properly. Currently, licq is not registered in the deb database as I installed the latest tarball.

Have a look at the equivs package. If you know how to write a Debian package control file, equivs will build you a pseudo-package from that which you can then go ahead and install. I suppose you could tweak the file list in /var/lib/dpkg/info/*.files, too, though that's slightly evil.

All the same, I find that Debian packages are easy enough to build that I usually don't run into this problem.

[reply] [top]

[»] Why not just use .deb?
by Vasilis Vasaitis - Sep 18th 2000 05:07:50

This whole article essentially says that everyone should just get rid of RPM and use DEB. The arguments at the end that support the opposite just aren't convincing. Let me elaborate:

RPM has a huge install base and is widely supported by many vendors and developers. Switching is not cost-effective. RPM is one of the major standards (the other being .deb), and you can't simply drop it.

Correct me if I'm wrong, but weren't some versions of RPM backwards incompatible? For example, I'm under the impression that packages created with RPM 3.x cannot be manipulated by RPM 2.x. So, if RPM 5.0 comes out and is essentially DEB, while still supporting the previous format (i.e. upwards compatible), I don't see what would be the problem.

RPM has a big acceptance among users and developers. Forcing them to change is not possible or desirable.

See above. RPM could be invisibly transformed to DEB, and people wouldn't be affected much.

The changes required to have a smoother integration with apt-get are mostly in the packaging policy; the changes needed in the tool itself are not great.

But changes will be needed anyway, so why not just make this big change once and for all?

Buildmasters and packaging people like file dependencies and consider them a Good Thing(tm).

Maybe, but users are really frustrated by them and consider them a Bad Thing (TM).

RPM has features not available in .deb, such as the ability to keep different versions of the same package installed as long as they don't overlap in the filesystem.

So what, Debian has trivially solved this problem by having packages called tcl8.0 and tcl8.2. And my experience with RPM based systems has shown me that this does more harm than good (a misfeature). Any other examples of RPM being better than DEB?

RPM may be adopted as an LSB standard.

Yeah, right. This reminds me the Microsoft style hype: "Windows will be the OS of the future, so switch now and ride the wave!"

All in all, Mr. Matsuoka tries really hard to say "use RPM, just change it," but it's not really working.

Vasilis

[reply] [top]

[»] About rpm vs deb
by cypherpunks - Sep 18th 2000 05:07:13

I'm an ex-redhat user, and now run debian, so I know a lot about how the two systems work, and most people complaining about .deb packages haven't actually used them, or don't really know them.
Firstly, people want non-interactive installs. That's fine, but debian has levels of configuration. You can set it to only show you critical configuration options. That means options you HAVE to answer or the package will not correctly install itself. Anyone who has run redhat knows that somethings need to be configured immediately upon install, or they open up your system to hackers / work faulty / ... What would be good is an option to not allow packages to be selected for install that have critical questions. That way you could install all the packages that ask no questions at the critical level, and have non-interactive installs. And you could still install all the other packages afterwards. There is no such thing as a fully non-interactive linux install. Everyone should know that. So don't complain about it.
Secondly, a lot of people seem to complain about not being able to configure debs, which is very ironic. Because first they complain about not wanting to configure it, and then about wanting to configure it. Well, debian has two ways. The debconf system, which allows nice configuration of all packages in several styles, after install, and the command dpkg-reconfigure which asks you the post-install configuration questions again.
It's a hard nut to swallow for a redhat user that deb is better than rpm at the moment. But I've had to overcome the cold fact that it's true myself. RPM can learn from deb. I'd like to see the two being interoperable. So debs can be installed on a redhat style system, and rpms on a debian style system.

[reply] [top]

[»] Interactive or not
by Calyth - Sep 18th 2000 04:06:02

As Michael Jenning's comment "Philosophy, not just design" points out, the difference between RPM and DEB is not in the source code to build the package manager.
RPM is more suitable for the newcomers and busy sysadmins, while Deb is more suitable for enthuasist who enjoys tweaking around. I've used both types of package manager, and personally I prefer Deb.
The interactive option may be a bit annoying at times, such as when I installed it at 4am and went to sleep, I found it was asking me to configure when I woke up, but it serves as ways to configure things that would set up the system once it finished the installing the packages. For example, when one installs MagicFilter it would scan for a valid /etc/printcap and see if it can get things working, or else it would ask you for configuration. This may be bad news for the sysadmin who's trying to install 50 machines, but if the sysadmin have the time to sit down and finish such questions, the system would be running when the configuration is over.
RPM has a funny dependency engine that when I used to use SuSE, it shows up some funny problems. Such as when I was trying to install a Gnome specific program, it ask me to install "gnome-libs", but I was already using gnome...... How could I run gnome without the libs? Isn't that inviting segfaults? I've no such problem with apt-get to install, in fact I don't need so much time to go to sites like here to hunt down rpms.
Deb is not perfect either. Since RPM dominates the user base (hey, there's way more people using rpms than debs), maintaining packages is harder as there's not as much hands to put things together. I found myself getting licq-0.76 while the latest is 0.85. Also, the interactiveness of deb doesn't always happen as there was only a handful of package asked me to configure at install and none ask me to configure once I had a running system.
One feature (If there's one, tell me please!) that I would like to see in rpm and deb is that the admin could tell rpm and deb that a tarball is installed; therefore maintaining the dependencies properly. Currently, licq is not registered in the deb database as I installed the latest tarball.
Merging rpm and deb is a great idea, because I believe that rpm users wanted apt-get while some deb users may want the silent, non-interactive rpm.

[reply] [top]

[»] all pipes were once made of lead...
by daevt - Sep 18th 2000 02:19:01

all pipes were once made of lead, but not any more. (apply liberally to discussion, use only in effected areas, avoid eye contact, do not injest, use only as directed.)

--
I hope that I never have to fall-back onto computer science, everything involved is made of metal and would probably break more than my fall...

[reply] [top]

[»] Hmm, I think you're off on two points.
by nate - Sep 18th 2000 00:44:27

Quoting:
- RPM has a huge install base and is widely supported by many vendors and developers. Switching is not cost-effective. RPM is one of the major standards (the other being .deb), and you can't simply drop it.
- RPM has a big acceptance among users and developers. Forcing them to change is not possible or desirable.

Not Quoting:
- RPM does have a huge install base. Cost-effectiveness is not relevant, nor is it easily judged or dismissed. Perhaps it is most cost effective to switch now, and find a proper solution. (I've personally had a hankering for a totally new filesystem (not internal filesystem structure), along the lines of NTFS, or Be's filesystem). RPM is one of the major standards. But I disagree: Yes, we can just drop it. I "just drop things" everyday, so does everyone else. I think what you mean is it would be ill-advised to lose the crudulity of the RPM name?

-"RPM does have big acceptance among end users. They cannot be forced to change." Linux (formerly) did not have big acceptance among end users (hehe, arguably still does not, but its rising, moot point), I was not forced to use it, I do. Point is: so what you can't force people to abandon RPMs, you don't need to force them.

I'd just like to find a way to put together a Correct packaging system, rather than another layer of patching on the current system. (Although It seems that the tendency for "correct" reimplementation is not terribly high, although it does take place).

[reply] [top]

[»] Automation
by chaos123 - Sep 17th 2000 23:58:13

Soemthing I've seen a lot of is RPM packages. I've been hacking together my homesystem for years, and as it's an Alpha, quite often, I have to compile things. I nade a vow after my last flush-and-reinstall that I'd install things into /usr and the like only with RPM.

Often, I use packages from different distributions; At first this was problematic, before file dependencies, before library version dependencies. SuSE was the worst-- they usually had a different version requirement than Mandrake and RedHat did.

All that went away with the dependency checking, and it's now at least safe for me to use packages from different distros.

Configuration: I've always loved RPM's unattendedness, but upgrading HTTPD, bind or certain other daemons is a chore I do not relish. Postgres is usually in this category as well, but the latest released RPM from RedHat did it very nicely: Install the default configuration, automatically do the Right Thing if it's absolutely sure, and when that failed (I upgraded from a nasty devel version), prompt the user as the service started for more info.

Partly, I agree with the comments above about "change or die", mostly aimed at sendmail... I don't use sendmail for just this reason: too hard to upgrade. I use postfix, which, ih having many different files controlling configuration and a better layout and design in general, makes upgrading much easier. I really would love to see sendmail change to be more easily configured... it'd have saved me a lot of headache.

An idea I had was to have script-sections in the .spec, perhaps a "%upgrade" section... it could look like this:

%upgrade 6.* 7.0
-shell commands to upgrade config file
6.* to 7.0 format

%upgrade 5.* 6.0
-shell commands to...

and it could chain them together to upgrade any supported version to the latest. If not, it can spit out a warning and leave it up to the user, or it could kludge it as best as possible, if the user desired.

My US2¢,
Chaos123

[reply] [top]

[»] RPM change is needed.
by tc - Sep 17th 2000 23:41:03

I would say we need a better upgrade path than RPM currently delivers. It's very nice to be on debian using dselect and select a package to install and have the system show you it's dependencies to install. I can't tell you how many time's I've HUNTED around for a library or some other package and not found it as I don't know what package name they gave the dependency. So you kind of have to guess. And I also believe it would be extremely useful if we had an install package such as Debian uses which allows the user some setup script which allows configuration during install. I have a problem in that I prefer using Debian's package system when it comes time to install packages or upgrade them. Yet, I am typing this message using Mandrake as I feel they have the best toy's. Loyal I'm not I guess. But I encourage others to be the best they can. Also, I think the new RPM package system should be UNIFIED into one package rather than RPM + AUTORPM or even dselect + apt so on so forth.

[reply] [top]

[»] rpm needs help
by Navarre - Sep 17th 2000 23:38:58

I've spent a lot of time with RedHat/Mandrake distros before moving to Debian. One of the main reasons why I doubt I'll ever go back is apt-get. I've spent hours in rpm hell resolving dependencies, and I haven't had to do it once since using Debian. The configuration scripts do a great job during install, and I recently upgraded my entire system to 2.2 with two commands. It worked perfectly. I can't say the same for Mandrake's upgrade, which horribly broke my system and I ended up installing from scratch.

[reply] [top]

[»] A few thoughts
by Cef - Sep 17th 2000 21:29:50

Similarly, all packages could include a "packagename-setup" tool that can be called *after* installation

How about this gets defined in the rpm as to what the config program is, and even the files that are used to store the config (especially useful for those programs that don't have config programs, and probably don't need one). This lets the user either fire up the config tool manually, or fire up rpm which fires up the config tool. Not sure of what the config tool or config files are for a package? Run an rpm query that'll tell you.

0. We DONT want the packaging system to be interactive

I agree and disagree. What we want is a package manager that can be interactive WHEN we want it to be, and not otherwise. Having such info available through rpm like the config program and config files makes this easy. In fact, a full installer could be simply a script that installs rpms and then runs the install script/prog provided after it's been installed. This is one point I like, as RH's installer never seems to be bug-free enough to cope with a particular way I've customised a system. *grin*

Also, you could always break your package into sections, breaking the config into a seperate rpm. You can even pre-package a number of different config types in seperate packages, which can fill common set-ups. Provide some that assume stuff, some that don't. In some make it all completely auto, in some don't. Give the user the option which to install. This is not ALWAYS the best method though, but it's something you can easily do now.

And I agree that .deb's need for upgrades to be babysat is... not optimul.

Thats the best bit about something like this config stuff. Allowing the package manager to control it means that this can all be done at the end, after the packages have been installed, or at least in some suitable order.

4. Another thing which this article does not address is uninstall.

This is a very hairy area. How to you guarantee things such as what you have installed haven't modified everything else ONCE you've done something else to the system. Sure you can roll-back (UGH!), but that takes you back to where you were just before you installed that package - which was 13 packages ago? Uninstall must be handled really well, but it'll take a lot of work. Till then, we have to rely on packages uninstalling their crap, and other packages not putting crap where they shouldn't. Not nice, I know.

Now this isn't aimed to be a answer to everything raised, but any suggestion can help. RPM needs work, yes, but like many GPL'd projects, it's still evolving. Get in and help if you can. If you can't, suggest ideas, help document it, test it. Don't just sit idle and complain.

Personally my biggest gripe is the way most config tools are written, wether they be linuxconf, yast, or even the one that comes with samba. They blow away huge parts of your config, and/or totally strip it of comments. In many cases, some of this can be attributed to the way many config files are structured (in most cases, they aren't structured at all). A little bit more regulation in these matters would be nice to see. You have to have exceptions to some cases though, as no format will handle every case - package managers included.

[reply] [top]

[»] New things under development
by Dave Cinege - Sep 17th 2000 18:49:00

The Linux Router Project is working on a radically different OS as well well as a new packaging system based on neither RPM or DEB.

For the last 3 years I've done nothing but heavy development work and sysadmin. (For self and on contract) I've worked with Solaris, Redhat, and especially Debian, and can honestly say when it comes to 'real world' production systems all of them suck for long term system maintainance.

Out of all of them Debian is still best all around. (System and packaging) But it's packaging system could be a hell of a lot better.
(I'm not still running 'slink' on my box because I want to...)

I think when we are done with our new breed OS, all the linux 'vendors' are going to be brought to task to look at how we did our packaging. Probably some of them will be adopting it. (That's is if we don't over take them all first. : >)

This is a feature list of what we are working on:

[name withheld]
==============
Defined:
A Unix type system software managment format, utilizing
a logical hiearchy for root layout, with de-centralized physical data
distribution.

Features:
No centralized package or physical data location

Allows conflicting packages/applications to be installed at the same time.
Package managment tool is able to enable or disable installed packages
dynamically, while preserving package configuration autonomy.

Generic and distributed nature. Multiple hosts can share the same
package installation via network mounts, while preserving package
configuration autonomy.

Allows hand fitting of root components (outside of /usr/local) with no
package conflicts

Logical root extensions for chroot, remote host, or virtual machine operation

'Open' physical packaging format allowing easy creation, extension, and future enhancment.

[reply] [top]

[»] No questions asked vs. questions asked
by Sesse - Sep 17th 2000 18:45:30

OK, I see a lot of discussion here whether installation should be totally automatic, or whether it should be allowed to ask some questions. Since gpm has been cited as an example here, allow me to use it again:

When I install gpm, should the program assume I've got a Microsoft 2-button mouse, or should it be allowed to ask? If it guesses, what if it guesses wrong? What would be easier for a newbie user -- answering a simple question upon installation, or spending a lot of time finding the appropriate configuration program when it doesn't work? Optionally, might the user miss something when the package hasn't been correctly configured? IMHO, it's a lot easier to ask the user a question early on, instead of just assuming that `one size fits all' and goofing. :-)

If all systems were equal, I'd say the RPM philosophy is right. But you and I have different mouse types (and other needs), so `automatic' might sound great in theory, but falls short in real life. (Building Debian packages is IMHO also incredibly easy with debmake -- no need for .spec files or anything :-) )

/* Steinar */

[reply] [top]

[»] undoing the damage of rpm
by John Califf - Sep 17th 2000 10:44:42

I'm compelled to comment on this article after just experiencing two of the pitfalls of rpm during a trivial upgrade. In doing an upgrade of the gpm (mouse) package, I had to use the --nodeps option because rpm had a dependency in another package for an earlier version of gpm. Why should that prevent an upgrade to a later version? Further, rpm didn't stop my gpm daemon prior to the upgrade, or restart it afterwards. Well, restarting it with a script could be a problem as rpm didn't know the paramaters gpm needed for my mouse anyway, as these setting are buried in an init file. Perhaps it could have asked.

There is a basic problem with rpm which is that it relies on an artificial database of what is installed and what the dependencies should be rather than relying on what is ACTUALLY INSTALLED on a system. How a file has been installed should be irrelevant. Instead of relying on an artificial database which is often incorrect, and can only be as good as the individual who created the package, rpm should check the system in the same way that the GNU autoconfig and automake utilities do. If the needed files are on the system in the standard locations (or perhaps others specified by the user if they can't be found in these locations) then the dependency requirements have been met and the installation proceeds. This also solves the problem of dependency checks which are passed but installations that don't work because a user or administrator has removed or altered files which are needed and rpm has no way of knowing this, as it refers only to its artificial database. The database is or should be what is actually installed, not what rpm thinks it should be. Rpm is incredibly unintelligent and can do great damage because of its stupidity.

Really, what does it take to create a locate database for libraries and includes which other packages could depend on for quick reference during installations? Examples of circular and failed dependencies are all too common with rpm, because people make mistakes in creating rpm packages. The only good thing about rpm is that it does keep a record of what is in a package and packages can be uninstalled cleanly.

It's not necessary to do away with rpm, but rather to come up with new installation procedure that totally ignores rpm's hard-coded dependencies and does an intelligent search of either the entire system or such a database made from a dependency locate utility as described above. Rpm can still be used for reference and removal of packages installed with rpm, but again a more intelligent way of maintaining an installation database is not impossible to design.

It's my feeling that rpm was originally designed by RedHat as a lockin tool to keep customers dependent on RedHat, and that RedHat didn't expect its package management system to be so widely adopted by other distributions. With automatic installation and upgrade from the internet, like aptget and Helix Gnome, lockin can now be achieved at a higher level. It's mostly home users and small business customers who can't afford full time sysadmins who are the victims here. Increasingly, they can't upgrade at all once they start using these services unless they use these services exclusively. It's only a matter of time before these and other services become pay services. So what if the packages are GPL'd. GPL means nothing to users and customers without the technical skills to bypass these lockin mechanisms and undo the damage.

The same is true of linuxconfig, yast and other automatic configuration utilities supplied with specific distros. Typically, these overwrite configuration scripts and settings created by a user or administrator instead of smoothly integrating them. Once you start using linuxconfig or yast, you have to keep using it for everything. SuSe, for example, refuses support to paying customers UNLESS they use the yast lockin gimmick. After installing RedHat, I was forced to remove linuxconfig and undo the damage to maintain my system as I want it maintained. Could a non-technical user do this? Who is really being served here, the customer or the vendor? The author of this article make a big deal about making things easier for distribution packagers with rpm. What about the customer? Let's make things easier for the customer and business will take care of itself. You might even make a profit by pleasing customers instead of insulting their intelligence with lockin gimmicks that would make Bill Gates blush.

There are many moral, business and philosophical issues involved in the packaging of Linux. I do know that someone could make a killing with a new distro that features intelligent package management as described above because this would give users the freedom to smoothly and reliably upgrade without worrying about HOW files were installed previously and without having to use a particular vendor's services and lockin gimmicks. I would be happy to work on such a distro and/or package management enhancement but don't have the capital or business expertise to get it started. (Please contact me by email if you do want to start such a venture).

In the meantime, my next distro when I get a new machine will definitely be Slackware, because Slackware does respect the intelligence of customers and is moving in the direction of easier upgrades and a more automated package management system without losing sight of its advantage. I do know that when I make mistakes with Slackware undoing the damage is much easier, because the user/administrator is in control of the system, not the other way around.

[reply] [top]

[»] My 2 cents
by John M. Morris - Sep 17th 2000 01:49:07

What I'd like to see as a solution is to keep updates 100% non-interactive during the actual upgrade, but also ensure you still have a working system afterwards without operator intervention. That means never leaving a .rpmsave or .rpmnew file behind.

I know that as things currently stand there ain't a chance in hell of me trusting any of the current automated RPM updating tools with a production machine. I want to watch the messages spew out and fix things right then instead of letting a cron script hose my systems and find out when the bot sees the webserver down at 3am and pages me.

RedHat needs to mandate that as of (for example) the release of RH7 they will not release an RPM that doesn't include a proper upgrade script that will gracefully merge the old configuration and that nobody else should either. That might mean a few packages would need some serious retrofitting or put a few limits on exactly how far this idea will apply, but if it became the 'law of the land' I doubt it would take more than a few weeks for everyone to write up some clever perl scripts.

A few obvious exceptions would probably have to be made as a stopgap, such as saying that changes to sendmail made through linuxconf would be preserved, but under no conditions would any automated tool be expected to merge a new sendmail.mc with a heavily site customized file. Longterm though, even sendmail needs to adapt, die or we just admit that sendmail isn't suitable for packaged systems that mortals would ever come in contact with, and leave it to the *BSD folks.

[reply] [top]

[»] Nice ideas but
by TGhost - Sep 16th 2000 22:20:22

First off the name has to change. We need a generic name not deb not rpm something that does the same thing but has a new name. What are the chances of RH buying into this :D. Second as for the LSB endorsing anything they are not worth the paper their charter is written on. They are tainted just looking at the things comming out of it shows you this. There are just to many conflicts of interest going on they have whored them selves out look at who hosts the site the mailing list etc... You have to stay neutral and this they have failed to do. Even if they say they aren't which they may not be you must stay neutral and accept nothing from the companies you are going to try and have conform to your standards.

[reply] [top]

[»] A few comments
by Claudio Matsuoka - Sep 16th 2000 17:19:55

I'm happy to see that some interesting points have been raised, as this was the main purpose of this editorial. Thanks for all the comments that have been posted.

Ingo: the intended audience of this essay is end users interested in software packages to see how they feel about using apt-get with RPM, and freshmeat is an obvious choice for this discussion. Advogato, for instance, targets a narrower audience. This should give enough food for thought for discussions at the technical RPM and APT forums. Regarding configuration, "packagename-setup" would do the job -- but all setup scripts should be run after unpacking all packages to avoid problems, except for those packages that must be installed and set up before the installation of another package. And as zforce pointed out, debian packages can be installed non-interactively, and in this case any configuration problems can be reported via email to the sysadmin.

Mark: Having each piece of software to handle its own configuration would certainly make the distribution package creation a much easier task. You could even argue that it would improve the quality of software packages by "natural selection", since badly written software won't configure themselves and would not be distributed. However, that doesn't reflect the reality of most software packages we have today, and rewriting them all is impractical. Packages also don't need to be configured in every minor detail -- the number of bits for key generation can be set to a default non-interactively, but a mail relay is harder to guess. Debian currently allows the administrator to set the interaction level from "ask me everything" to completely non-interactive, and dpkg-reconfigure allows you to reconfigure them later. I agree that the rpmnew/rpmsave system does not work, and automatic upgrade doesn't work always (e.g. in a recent bind upgrade in Debian the system just asked me to update the configuration manually) -- if it attempts to upgrade configuration files automatically, it's very important to alert the administrator when it can't be done, otherwise it will be worse than doing everything by hand. For point 4, you must have a level of trust in the package maintainer, otherwise you'll have to audit and build every piece of software you install. Security concerns in auto updating have been discussed in a previous freshmeat editorial.

Darxus: that would be nice, but today even mixing RPMs from two different distributions is risky. In many cases using RPMs from another version of the same distribution can lead to problems.

zforce: I like debconf, and it has been working well in my woody boxes (that have been installed as hamm and then upgraded to slink and potato along the years). I can only remember two problems in all the upgrades: dhcp-client in hamm->slink and lvm in slink->potato. I don't know, however, if porting it to a non-Debian distribution is cost-effective.

Sam: In fact no service must be configured in installation, but they need to be configured before it can be used. And it's advisable to stop the running service before installing, so if you want to have the service running again after installation, you must configure it at some point between installation and service restart. This can, of course, be done manually by the administrator, but it's not a very comfortable task for non-skilled users who update their workstations. Even if you don't update frequently, you must do that to fix security problems.

Michael: Yes, I understand this is a philosophy issue, but if I take it as an axiom I couldn't start the discussion at all. You say that RPM was aimed at less experienced user, and that's why RPM is what it is -- and I totally agree. I see, however, that upgrading with apt-get is much less painful to the novice user than dealing with rpmsave/rpmnew files. Due to its design decisions, RPM became intrinsically hard to mix with APT, and changing it would be against its philosophy. So the choices are:

• Do nothing and have partial apt-get functionality
• Allow RPM to evolve to a form it would be more in tune with its original purpose.
• Fork.

[reply] [top]

[»] apt-get
by Jason Gunthorpe - Sep 16th 2000 16:26:42

Claudio makes good points, if you want APT to operate in a meaningful manner with RPM packages you must have .rpm files that conform to a strong policy that can enable APT to work. There is not any alternative.

Primarily, I see this as the responsibility of the RPM distribution vendors and it is partly why I have never personally bothered to make an APT that supports RPM - it is a pointless excercise without a vendor developing packages to operate with it.

Connectiva has a nice little addition to libapt-pkg to enable it to load in RPM index files. But IMHO there are still some unresolvable problems with the RPM system - they all boil down to the fact that you need to perform an analysis on files as well as on package meta data with RPM. You need to download a full listing of every file in every package and you need to do very expensive processing on this data!

At first blush I don't see this as impacting the operational memory usage of APT programs, it will only make startup slow (tolerable) and apt-get update download lots more data. (perhaps tolerable)

All this is required to support two seemingly harmless RPM features - file dependencies and installing two versions of the same package at the same time. The latter is particularly expensive because you must answer the question 'Can I install pkg v1 and v2 - do their files overlap?' for every single available rpm while loading the index data. (Note: AFAIK Connectiva has not yet implemented a solution to this problem, this is so far the best stab at it)

I belive that Claudio's points are important for RPM distributions, and must be considered. We already see

Comments about other comments:

* Non-interactive operation is entirely possible to do while still allowing automated upgrades. Debian is working on this already. However we have also found that the majority of packages do not have any need to prompt the user at all.

* Merging RPM and DEB may be entirely infeasable without breaking one or both systems. At the most fundamental level RPM and DEB do not compare version numbers in the same way, and do not compare dependencies in the same way. Secondly, the RPM features that require a full file contents list are unnaceptable overhead for Debian - a big part of our market is end user automatic upgrades, making that download 3x as large is very bad. [Off the cuff estimate based on the size of Debian contents-i386.gz and packages.gz]

* (WRT to fileutils rpm, and post inst scripts) Debian solves this problem by marking certain packages as Essential. This basically means that package scripts can freely use anything in these essential packages without explicit dependencies. This simplifiies things and reduces the number of edges in the dep graph. Adding such a feature to RPM would be trivial.

* Debian does have the notion of a source package - it is just not a single file object like you see in RPM. A Source package is fully defined by the .dsc files you see in our archive. An excellent advantage of this is that we can have source packages sharing the same files (primarily upstream tar ball).

[reply] [top]

[»] Deferred package configuration
by zforce - Sep 16th 2000 11:35:42

I've seen many people here saying, "I don't like to have to answer questions to install my application." Now anyone with a decent version of debian -- that is potato and woody -- will know of a tool called debconf. All configuration for deb files is now done through the debconf system. You can configure the level of detail you wish to supply to debconf, if you want to supply any information at all, and you can enter the information at a deferred time if you so wish. To me, this seems like the perfect implementation.

Ian

[reply] [top]

[»] I'd prefer a merging of the .deb & .rpm formats
by Darxus - Sep 16th 2000 10:59:26

I'd much rather see the formats merged, and full package compatability between redhat and debian. At least, I think it's the right goal to strive for.

And I agree that .deb's need for upgrades to be babysat is... not optimul.

[reply] [top]

[»] I totally disagree
by Mark Veltzer - Sep 16th 2000 08:42:02

Ok. There are so many hidden assumptions here in the article that
it seems too much to rebbutle. Let me start:
0. We DONT want the packaging system to be interactive (.deb is a very BAD example of that). We want the SOFTWARE installed to be interactive and provide a configuration utility. When the package itself is interactive the original package programmer has less to do and you wind up with a package that needs to be reinstalled to reconfigure. This is very bad from a software development stand as it produces very low quality software and package systems should not forgive software that cannot be reconfigured by doing it for them. Besides, if Im installing netscape and it depends on a new secure protocol packages you mean that I have to answer questions like - "Number of bits in key generation algorithm ring = 56 ? (correct ?) "... All this for installing netscape ?
1. Another reason package interactive configuration is bad is that in the future there will many more packages with a lot of dependencies and installing one may cause installation of a 100 packages - do we realy want to answer all of their questions about configuration ? let them install with default configuration and provide reconfig utilities.
2. DONT put any semi aritificial intelligence features in package management system (not at the core anyway...). We all know that those features are not realy intelligent. Take for example the RPM feature of keeping the old configuration files. It is a total bullshit feature. What if the new version also has a new format for the configuration file ? I'll wind up with an application that doesnt work. Flexibility for the programmer behind the application should be maintained. What the package management system should give the programmer behind the application is the ability to run a special tool which will be in the package to do an upgrade and THATS it!!!!. This way I could move from standard .rc file format to XML .rc and not worry about my users (I'll just add a script to the package that converts the old format to XML and that script will be run by the package management tool when it detects that theres an upgrade going on...). In any case, upgrade is a messy business, so dont let package management systems fool you into thinking that they handle it "automatically..".
3. All in all, "smart" features should not enter the package management tools core system (we all know that that is wrong in any software system...). I'd much prefer a simple package management tool with a strong database behind it and a simple policy about upgrades - it installs the new packages and tells you about configuration files that you messed with and puts copies of them on the side for you to re-apply your changes. At least then I'll know that upgrade is complicated rather than be lied to and find that when I cant run the application, or worse, when the application runs in a mysterious buggy way...
4. Another thing which this article does not address is uninstall. The biggest thing about uninstall is that you want it to GUARANTEE that the uninstall returns the system to the same state before the install. This means that pre and post scripts are BAD. Yes. Im suggesting dumping them all together. They are a big security hole (dont talk about package source authentication - what if the programmer of the script had a bug and removed my kernel ? what if I dont know the company giving me the package and the package is a trojan into my system ? stop thinking about geeks who will scan the scripts with their eyes and think about my mother double clicking the package... besides - by definition I'm a qualified geek and I've installed hundreds of rpms and havent scaned any of them - who has the time ?). The idea is that pre and post stages will still be maintained but the packager will only have a limited selection of actions that could be performed at these stages and each of them will be reversible (and will actually be reversed) by the uninstall process. All in all Its a good idea to push software writers to the edge where they think that they have to do all of their configuration with a tool that they provide (they hate that but that is the future...).

Mark

[reply] [top]

[»] developer talk, or what?
by Ingo Luetkebohle - Sep 16th 2000 08:26:46

Funny to see an editorial about this but no mail on rpm-list -- which is supposed to be about this kind of things.

Go here: https://listman.redhat.com/mailman/listinfo/rpm-list

This isn't meant as a flame, though. The issues brough up here are certainly very valid. I'm not sure they are RPM's problem, though. IMHO, a convention on package contents would be just as good, without any changes to the package format. For example, many libraries picked up the convention to include a "libraryname-config" tool, that prints out all flags needed to use the library. Similarly, all packages could include a "packagename-setup" tool that can be called *after* installation

Why not put it in the package format? Because RPM was meant for unattended installation and thats a feature worth keeping.

[reply] [top]