Slashdot: News for Nerds


Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Is RPM Doomed?

michael posted more than 12 years ago | from the apt-get-dist-upgrade dept.

Linux 691

Ladislav Bodnar writes "This is an opinion piece offering solutions for all the ills of the RPM Package Manager. It has been written with Slashdot in mind - it is a fairly controversial topic and I would like to hear the experiences and views of other users who have tried different package formats and different Linux distributions. The conclusions are pretty straightforward - either the big RPM-based distributions get together and develop a common standard or we will migrate to distributions offering more sophisticated and trouble-free package management. Note: the main server allows a maximum of 100 simultaneous connections. To limit the /. effect, here are two other mirrors: mirror-us and mirror-hu (the second one has larger fonts). Thanks in advance for publishing the story."

cancel ×


cool (0, Flamebait)

xeeno (313431) | more than 12 years ago | (#3710613)

So. The only contribution that redhat has ever made that was worthwhile to the linux community might be headed out the door.
What a legacy.

Like a Catholic Priest... (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3710621)

...this lamer non-first poster must be defrocked!

Or fondled.

Writing something controversial... (0)

Anonymous Coward | more than 12 years ago | (#3710617)

with Slashdot in mind. Isn't that normally called trolling?

For example: FreeBSD's ports kick RPM's ass!

Is RPN dead? (1, Funny)

Anonymous Coward | more than 12 years ago | (#3710619)

Those of you who are in college now -- do you youngsters still use RPN on HP calculators?

Re:Is RPN dead? (1)

Indes (323481) | more than 12 years ago | (#3710724)

I'm in High School and use an HP 48G+,

It uses RPN.. I dunno where I'd be without it. :-)

We need a smarter packe system (0)

Anonymous Coward | more than 12 years ago | (#3710626)

I hate it! You need to compile a new RPM for each platform

What we need is a smart .tar.bz2 package which dectects what OS your using, and compiles and installs automagicly with a easy to use gui and a powerful cli interface

Okay, here (3, Informative)

0x0d0a (568518) | more than 12 years ago | (#3710685)

I hate it! You need to compile a new RPM for each platform

What we needis a smart .tar.gz2 package which detects what OS your using, and compiles and installs automagically with an easy to use gui and a powerful cli interface

Well, hell.


# Demonstration that RPM ain't all that bad
# Copyright 2002, 0x0d0a
# This code placed under the GPL
# Should compute proper buildroot, etc
# Be damn sure not to set buildroot to /
# or something similar -- rm -rf would
# then suck severely
# Set our_rpm_buildroot appropriately
# Usage: foo.tar.bz2
ni ce -20 rpm -tb "$@" && rpm -Uvh `find $our_rpm_buildroot -type f` && rm -f `find $our_rpm_buildroot -type f`

Okay, I grant that there's no gui, but you get all the many CLI options of RPM. Voila!

People love to bash RPM, but it's a pretty sweet system (except the move to the newer underlying dbfile...screw transactions, I can always rebuild the database if it gets corrupted and it takes *much* longer to install and query than things did back with rpm 3.0). If it's too simple for you, it's really easy to use it as a back end and slap something on top of it.

Note: this is a one minute hack and may not even run, much less be safe for your's an example, not intended to be used. And hell, running random stuff from people on Slashdot as root just isn't a great idea. :-)

*RPM is dying (1, Funny)

Anonymous Coward | more than 12 years ago | (#3710627)

It is now official - Netcraft has confirmed: *RPM is dying blah blah blah

apt-get is nice (2, Informative)

Bloody Bastard (562228) | more than 12 years ago | (#3710628)

I don't have problems with RPMs at all. I use apt-get since it was first introduced in Conectiva Linux, and I'm now using it in a Red Hat box. I upgraded it from 7.2 to 7.3, and the only problem I had was lack of space in /var to download the files (not my fault, but from the former sysadmin).

Re:apt-get is nice (1)

morgajel (568462) | more than 12 years ago | (#3710729)

not sure if this will help alleviate your position, but I know of the debian side of apt get, there's "apt-get clean" which removes current packages from the /var/cache/apt/archives. This will remove them if you have a bunch of crap you don't need anymore.

oh course if the drive is just plain SMALL, you could always go ghetto, throw another drive in, and mount it as /archives and thow this at it

#move all files and folder from /var/cache/apt/archives to /archives
mv -r /var/cache/apt/archives/* /archives
#remove /var/cache/apt/archives directory
rm -rf /var/cache/apt/archives
#replace directory with a symbolic link
ln -s /archives /var/cache/apt/archives

that should work, but keep in mind I just woke up, so this code may completely pooch your machine. think it out first and make sure it won't. Not sure if apt will thow a hissy fit over that or not.
/me checks his email and goes back to sleep

Re:apt-get is nice (0)

Anonymous Coward | more than 12 years ago | (#3710733)

Since recently installing Red Hat 7.3, I have happily been using apt-rpm with the repository. It has been great for installing software that has specific dependency issues. However, there are two concerns I have (this applies to apt on Debian, as well):

1. I recently got broadband (finally available in my area), which makes polling the apt repository a piece of cake. How easy would apt or apt-rpm be to use if I had to install software from floppy or from CD-ROM? How does this compare with Windows installers?

2. Audacity and are not available on And, the Mozilla and Abiword packages are not to the current releases. What options do I have to install or update these applications, if I can't find a suitable repository? (This is mostly rhetorical: Actually, I installed both Mozilla and from scripts provided by each project. Audacity provided necessary RPMs. However, Abiword seems broken -- can't get the latest installed.)


Re:apt-get is nice (5, Informative)

nehril (115874) | more than 12 years ago | (#3710743)

someone please correct me if I'm wrong, but doesn't this article suffer from a fundamental misunderstanding? you cannot compare apt-get to rpm files. apt-get is a system for installing .debs and their dependencies. there are similar systems for rpms (apt-rpm or red carpet).

.debs suffer from all the same problems he complained about rpms having, because .debs are just a single package file. so do source code files (a la gentoo etc), since alot of your source code out there wont even ./configure without the right stuff in place. where debian has apt-get to manage the dependency nightmare, gentoo has emerge.

what he is really bellyaching about is the fact that some big rpm based distros (mandrake and redhat) don't come with free dependency management software. 99% of his anti-rpm comments are not even wrong, they are wholly irrelevant.

The last 1% that might have value is the fact that developers can't make a "universal" rpm due to all the differences in filesystem layouts among rpm based distros (note that this can a problem with .debs too). From an end user perspective even this is not a problem with a dependency manager in place. since it will find the "right stuff" for you.

Gah (-1)

Mao Zedong (467890) | more than 12 years ago | (#3710631)

Sundays suck.

Re:Gah (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#3710646)

Some Sundays perhaps, but not Sundays when Tiger and Sergio and going head to head at the US Open!!

Re:Gah (0)

Anonymous Coward | more than 12 years ago | (#3710666)

I hate tennis.

Linked too early perhaps? (1)

nurb432 (527695) | more than 12 years ago | (#3710632)

From the page...

"This article is currently under preparation. Please do not post links to it and do not submit it to any new sites. Thank you."

Not on all mirrors (1)

cheezycrust (138235) | more than 12 years ago | (#3710650)

Not all mirrors have this notice. So the mirror you visited needs an update.

standardized locations, etc. (3, Insightful)

nilstar (412094) | more than 12 years ago | (#3710634)

I think the biggest thing we need with rpm (and other distro systems) is standardized package locations. That would help, *extremely*.... as well versioning control needs to be better. For example, I hate having to have 2-10 different versions of libraries due to programs requesting their own version, even though the newer libraries could do the job of the old ones. As well, when the rpm asks for another rpm which is not installed, but the libraries are on your machine (in the right location) it is frustrating.

I hate to say it, but maybe we need a standardized "registry" idea like in MS Windows? I hate to say it, but they do have a good idea with that.

Re:standardized locations, etc. (5, Informative)

TrentC (11023) | more than 12 years ago | (#3710667)

I think the biggest thing we need with rpm (and other distro systems) is standardized package locations.

You mean something like a Filesystem Hierarchy Standard [] ? Or maybe even a Linux Standard Base [] ?

Jay (=
(Is there a website that rates distributions according to their adherance to these standards?)

Re:standardized locations, etc. (3, Informative)

smagoun (546733) | more than 12 years ago | (#3710686)

One of the problems you bump into with standard, one-size-fits-all packages is that APIs change, and bugs get fixed/introduced. Assume package A v1.2 was compiled against package B v3.6. Now package C comes along. Package C needs package B v4.0, so it upgrades package B. In the switch from v3.7 to v4.0, however, the API changed and a misfeature was corrected. Now assume package A relies on the old API and the presence/functionality of the misfeature. Now assume package A is no longer actively developed.

This situation (and ones like it) happen all the time. That's one reason why programs often get their own copy of a library, even though it sucks from an end-user standpoint.

Nevertheless, you're right....versioning needs to be better.

Re:standardized locations, etc. (0)

HD Webdev (247266) | more than 12 years ago | (#3710698)

Now assume package A relies on the old API and the presence/functionality of the misfeature.

Package A relying on a misfeature is Bad and Wrong.

Re:standardized locations, etc. (2, Interesting)

Vlad_the_Inhaler (32958) | more than 12 years ago | (#3710744)

Package A will have been written for and tested on the API as it was defined at the time.
The author(s) could not know what part of the API was going to become obsolete.
I work on mainframes where things are a lot more stable, but occasionally some interface is changed and something has to be done. If we are lucky (most cases), that 'something' is just recompiling. If it goes beyond that, then most times the software vendor warns us of impending problems.

single point of failure (2, Informative)

Futurepower(R) (558542) | more than 12 years ago | (#3710688)

The registry in Windows creates a single point of failure. The point of the registry seems to be copy protection. The registry contains incomprehensible data. It is an area meant to be outside the user's control.

Re:single point of failure (3, Funny)

Graymalkin (13732) | more than 12 years ago | (#3710722)

Well I'm sure glad Linux uses /etc to store confiruation data. Having 50 different styles of configuration files sure does make one's life easier.

I suggest a browseable, book-like interface. (2)

Futurepower(R) (558542) | more than 12 years ago | (#3710752)

Having 50 (only that many) different styles of configuration files definitely makes things tough. However, the information is not hidden from the user, as it is in Windows.

It would be great if someone standardized Linux configuration files. I suggest a browseable, book-like or PDF-like interface like that in Ganymede. Each package would be expected to write their own interface to the configurator. That way, authors could have any configuration file format they wanted, but there would also be a standard GUI interface.

Re:single point of failure (4, Informative)

0x0d0a (568518) | more than 12 years ago | (#3710758)

The syntax of UNIX config files is pretty standard (barring the occasional ugly misfit like sendmail -- use postfix instead).

And all the Windows registry does is give a standard format for storing individual values (how should I store a string, how should I store a DWORD) and provide a hierarchy. It says nothing about format or structure within a single app.

If you want to turn on, say, mail relaying in postfix on Linux, then you look for the entry called mail_relay (or whatever) that's commented out and contains a helpful set of comments right above the config entry. On Windows, the equivalent is to go into the registry to some unspecified key, create an unspecified value there and then set it to some unspecified value.

Of course, most people just use a front end on Windows -- like a preferences or options dialog -- because the registry is next to useless to actually interact with. You can do the same thing on Linux, which is done by GNOME and friends to make things more convenient for computer novices.

Also, if the Windows registry gets corrupted, you have a big problem. If a single text format config file gets corrupted, you can probably fix it yourself. If you can't...well, it's a single file down the drain. Reconfigure that single app. Your entire system doesn't become unbootable, a la Windows.

Re:single point of failure (0)

Anonymous Coward | more than 12 years ago | (#3710764)

I was just thinking about this very thing, yesterday...

Speaking within a desktop/workstation frame of mind: While Windows Registry is a mess, it is a relatively easy way to control system behavior from a single point, once you've become familiar with its idiosyncrasies. Meanwhile, editing myriad conf files gets to be more and more a chore, the more complex I make my system. The registry idea seems to offer a nice balance between controlling many applications and the need for simplicity.

I agree with the original post... I think I'd kind of like to see s registry-like feature in Linux distros, only this time done right -- something much more easily attained in an Open Source framework.

Apart from the single point of failure argument (let's see... are there any single points of failure on extant distros? hmmm...), are there any better arguments against a registry-like feature?


Re:standardized locations, etc. (5, Interesting)

0x0d0a (568518) | more than 12 years ago | (#3710730)

I think the biggest thing we need with rpm (and other distro systems) is standardized package locations.

That's already done in the LSB.

The problem is that each rpm is required to contain a static list of files it installs *with pathnames*. The nice thing about this is that it lets you run rpm -qip foo.i386.rpm without executing any code (sandboxed or otherwise) to see the list of files. The stupid thing is that there then has to be a totally different rpm for every distro and every maintainer.

In addition, it means that the maintainers need to keep *two* lists of what files are in the package -- one list for "make install" and the other for rpm. This is probably the most annoying design decision of RPM I've seen. There needs to be a FILES file with a list of installed files with a gen-files script (that runs sandboxed to build FILES for not-yet-installed packages and is run at package installation time to generate FILES). Have the Makefiles read this for make install. This would make life easier for maintainers (one list of files to install), would make RPMs more reliable (no accidental adding of a file to the Makefile but not to the spec file), and would let an RPM work on any distro (if we ever get the gcc-2.7, gcc-2.96, gcc-3 stuff worked out).

even though the newer libraries could do the job of the older ones

This is true for minor version number increases, but for a major version number change, newer libraries cannot simply link to the program.

Also, the registry is a fucking stupid idea. (despite the fact that GNOME and KDE are mindlessly cloning it). The registry causes more problems than anything else I've seen on a Windows system. The MacOS did things right -- let all your centralized databases just be caches for data that can be rebuilt from files around your system. If something gets borked or corrupted...that's okay. Absolutely do *not* make your single copy of data a registry -- put the masters around the system, and let the centralized db be rebuilt if necessary.

Also, registries require "installations" and "uninstallations" instead of just copying files. You can just copy appropriate files from one system to another and run code on a Linux or MacOS box. On a Windows box, you're in for running installers to poke at the registry. And finally, I've seen tons of broken Windows installers that poke at registry entries and end up completely screwing up data that some other app uses. For example, a friend once had Sonique and WinAmp installed, but couldn't associate mp3s with either. I took a look at the registry -- Microsoft's two-entry file association scheme let the extension entry point to a nonexistent application entry, IIRC. As a result, the mp3 entry didn't show up in the Folder Options dialog in Explorer, and couldn't be reassigned, and WinAmp and Sonique kept giving errors when trying to grab associations.

The day any distro starts requiring a registry is the day I never touch that distro again. Right now, I can just uninstall GNOME if I want to do so.

Oh, and another thing. The Windows registry is a *massive* shared database. As a result, tons of stuff modifies it and causes internal fragmentation and loss of physical continuity between related keys. Then all apps use the registry heavily (God, I hate apps that poll it), so you get slow app launch times, that annoying disk churning that you hear on Windows boxes...rrrgh.

Take a look at .dll registration. On Windows, the only way the OS knows about a .systemwide dll is when you've added an entry to the registry for it. On ldconfig, and it rebuilds the systemwide cache (, which is significantly faster (contiguous, not incrementally modified, not modified by all sorts of other apps storing filename associations and the like) to read.

The registry is basically a hack, because Windows *used* to have what MS considered a worse scheme (.ini files). It isn't a very well thought out system.

Re:standardized locations, etc. (0)

Anonymous Coward | more than 12 years ago | (#3710759)

Mod this up somebody. I agree wholeheartedly with everything he said. The registry breaks every principle of common sense engineering.

Re:standardized locations, etc. (2)

Fluffy the Cat (29157) | more than 12 years ago | (#3710760)

I hate having to have 2-10 different versions of libraries due to prorams requesting their own version, even though the newer libraries could do the job of the old ones

Any program linked against a library with the same major version number and the same or lower version number than the library installed should work. If the program depends on a specific minor version (as opposed to "a specific minor version or greater"), it's broken. If you have, and you should be able to delete all of them except for the last and expect things to keep working. Applications are linked against the major version number, so they'll be using the more recent version already (run ldd on a binary and look at the first column - that's what the program is looking for, and the last column is what it's using)

Now, the problem arises when you have applications linked against different major versions. The major version is supposed to be incremented when an incompatible change in the ABI is made - that is, without recompilation, a program linked against will not work with (well, it might - the change may be limited to a specific part of the library that the program doesn't use. But you can't guarantee that).

So, if you have dependencies on lots of libraries with the same major version but different minor versions, your packages are broken. If you have dependencies on lots of libraries with different major numbers, then that's unavoidable and nothing to do with the packaging system.

Has anyone ever tried.. (2, Informative)

ChronoZ (561096) | more than 12 years ago | (#3710635)

various alternatives to RPM packaging? I don't know much about this, but I've found QNX's [] Package Installer to be quite efficient and trouble-free (at least in 6.1, can't say much on the new one in 6.2NC) compared to what many experience with RPMs..
Then again, RPMs would work better if more distributions were a little more uniform in their cores (UnitedLinux might solve this?)

Is RPM Doomed... (0)

Anonymous Coward | more than 12 years ago | (#3710636)

Who cares?

Solaris packaging (0, Troll)

Anonymous Coward | more than 12 years ago | (#3710639)

The Solaris pkg method is tight, easy to do and proven. Linux could definately use this. Die RPM Die.

Re:Solaris packaging (1)

grokBoy (582119) | more than 12 years ago | (#3710652)

A quick google reveals that there are already several open source ports of pkgadd/pkginfo etc available for Linux, but with Sun's foray into the Linux market, perhaps an 'official' port will happen sooner than you think.

Re:Solaris packaging (2, Informative)

mindstrm (20013) | more than 12 years ago | (#3710692)

What features of the solaris package management and/or solaris packages themselves do you want to see? Because if it's just about nice, neat clean packages that install trouble free.... well, let's just say it's entirely easy to produce a solaris package that sucks.

The point is.. RPM is not the culprit; multiple vendors using the same package but systems that are rather different sucks.

debian packages work well because the debian world is rather focused. Because we ensure that all dependencies can also be met from debian packages in the same distirubtion, etcetera.

If you use redhat and only redhat official packages, it works great too (well, insomuch as redhat can work great)

Gentoo's Portage system r00lz (4, Informative)

rizzo (21697) | more than 12 years ago | (#3710641)

Gentoo Linux [] uses a system called "portage" which will download, compile, and install programs from source (binary for some packages). It is fantastic. Similar to apt it will check for dependencies and get those also. But the use of source is what turns me on. I'm converting all my linux boxen to it. Even inspired me to slice up the disk on my Win2000 box and go dual-boot.

Talk about a gimmick (1, Troll)

Anomolous Cow Herd (457746) | more than 12 years ago | (#3710705)

Compiling it from source is almost never different from just grabbing a binary package and installing it. If it wasn't already compiled with the appropriate GCC optimizations, chances are compiling in those optimizations now will just lead to random instability. It's just an excuse for dorks in their basement with more time than brains to feel good about their l337 lunix b0x3n.

Re:Talk about a gimmick (0)

Anonymous Coward | more than 12 years ago | (#3710716)

Dude -- that was one of the weakest, most transparent trolling attempts I've ever seen. If that's the best you can do, well, just please, please, please don't pollute the gene pool.

Re:Talk about a gimmick (0)

Anonymous Coward | more than 12 years ago | (#3710757)

Dude, that was one of the weakest counter-troll posts I've ever heard. Luckily, nobody ever reads counter-counter-troll posts in a serious frame of mind, so my post is super fucking 1337.


Re:Gentoo's Portage system r00lz (2)

0x0d0a (568518) | more than 12 years ago | (#3710735)

And there are plenty of front ends to rpm that can also get dependencies. If rpm is too low-level for you, that's why it was designed to be *really easy* to write front ends for, what with rpmlib and --queryformat.

Mirrors (5, Informative)

cheezycrust (138235) | more than 12 years ago | (#3710643)

If the other links are overloaded, you can read the story on my site [] . Maybe other mirrors should be posted in this thread.

I like Slackware's .tgz (2, Informative)

Xpilot (117961) | more than 12 years ago | (#3710645)

No depency checking, but it also means that you don't have the problem of circular dependecies and the like. Plus you can open it with tar and gzip. Linux Packages [] is a great place to look for pre-built Slack packages.

I used to use RPM, but now that I've converted to Slack, I don't miss it one bit.

Re:I like Slackware's .tgz (2, Interesting)

BrokenHalo (565198) | more than 12 years ago | (#3710736)

I was just about to post something to the same effect. Having spent many hours trying to fix or work around broken package dependencies with RPM on RedHat and more recently Mandrake, I recently ditched both in favour of Slackware which I have found _much_ easier to maintain. Good to see I'm not alone in this...

Re:I like Slackware's .tgz (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3710748)

Circular dependencies. Yeah right. Listen, if you want a package manager to wildly ignore dependencies and act like stupid tar, use "--nodeps" and "--force" with rpm.

I can't stand it when people complain about rpm trying to keep them out of trouble. You can make rpm as stupid as you want with "--nodeps" and "--force". If you really love ignorance, use rpm2cpio and unpack the thing straight.

Luke, use the source... (4, Interesting)

peterdaly (123554) | more than 12 years ago | (#3710648)

I administer a few RedHat servers, mostly 6.2, and 7.2 which each perform a different function. If an RPM is offered for a piece of software I need to install, I usually download that first.

If the rpm install fails, I will spend about 3 minutes troubleshooting the issue. If I can't get it to go, I download the source and compile from scratch. 9 times out of 10 this works without having to figure out dependancies.

RPM works great when the envirnment is exactly the same as the build envirnment. When it's not...well, it just plain sucks. Source almost always works without incident.

Really, there is nothing to difficult about:
make install

Although it only works for products where the source is openly available.

RedHat needs a compile from source package format that most people can figure out. srpms may do it, but I have no clue how to use them.


Re:Luke, use the source... (3, Informative)

blaze-x (304666) | more than 12 years ago | (#3710673)

> I administer a few RedHat servers...

Once you administer 20+ of 'em with other admins, you are going to need a package management system.

Unless you think keeping notes really works :)


Re:Luke, use the source... (3, Insightful)

garett_spencley (193892) | more than 12 years ago | (#3710678)

I'm an administrator too but I try my hardest *never* to install from source. This is because of security and ease of maintenance.

The main concern is that if I install OpenSSH from source on all 50 of my servers when it comes time to patch it I've got myself a little inconvencience. I would most likely compile it on one machine, tar up the source directory (complete with new binaries) and do a 'make install' on all 50 machines so I don't have to recompile for each box. But this is still going to take me a lot of time.

So therefore we've set some policies in place to make keeping systems up to date and secure easy:

For starters, we've standardized on Mandrake for Linux. This helps a lot because if we have a single rpm to install it will install on all of our servers.

We also mirror the updates locally so that we don't have to worry about slow downloads and we make heavy use of urpmi to automatically grab all the updates, check dependancies, gpg signatures and install them for us.

We don't install from source unless we absolutely have to. Actually, we try not to install any software that doesn't come with Mandrake but obviously this isn't always possible. In those cases we follow the convention where everything goes in /opt/pkg_name so we can easily get rid of them if we have to.

I really like RPM for this reason. However, as you stated as long as the systems the RPM was compiled for is roughly the same it will work well. Which is why we standardized on one distro.


Re:Luke, use the source... (1)

scotty (5588) | more than 12 years ago | (#3710728)

We too tried to standardise all our boxes to Mandrake Linux at work, and tried to install nothing but mdk-rpms. If we cannot find the packages we need in the standard distribution, we will then try to download the SRPM from Mandrake cooker and then build it (which is not always stable). If no SRPM is available, we will still try to write our own spec to build the SRPM from tarballs. But we will NEVER install from the source directly. Two things I really like about Mandrake - urpmi and cooker.

Re:Luke, use the source... (0)

Anonymous Coward | more than 12 years ago | (#3710680)

Not difficult, just rpm --rebuild package.src.rpm

Re:Luke, use the source... (2, Informative)

Squeezer (132342) | more than 12 years ago | (#3710693)

RedHat needs a compile from source package format that most people can figure out. srpms may do it, but I have no clue how to use them.

rpm --rebuild package-version.srpm
rpm -Uvh /usr/src/redhat/RPMS/i386/package-version.arc h.rpm

Or if the .tar.gz you extracted has a spec file:

rpm -bb package.spec
rpm -Uvh /usr/src/redhat/RPMS/i386/package-version.arc h.rpm

Re:Luke, use the source... (1)

BrokenHalo (565198) | more than 12 years ago | (#3710754)

It also helps to have appropriate compiler flags for your box set in your shell environment, for example

export CFLAGS="-O9 -mcpu=athlon -march=athlon -pipe"

Re:Luke, use the source... (0)

Anonymous Coward | more than 12 years ago | (#3710713)

make uninstall is where the trouble starts.

Re:Luke, use the source... (2, Interesting)

grazzy (56382) | more than 12 years ago | (#3710723)

True. I've been working with this exact method for years aswell.

I see nothing wrong about RPM compared to other systems, I can see why people running say Debian whine about RPM because .rpms isnt supported on THEIR system.. and I dont see as many .deb out there as there are .rpm ..

So either way if rpm is worse or better than .deb its a standard. And standards are standards because people use them - and like them. Its not .rpm that should change, maybe its .deb.

real men (0)

Anonymous Coward | more than 12 years ago | (#3710649)

Real men use
tar xjf coolprog.tar.bz2
make install

Re:real men (0)

Anonymous Coward | more than 12 years ago | (#3710660)

Real men always run as root... none of this silly su nonsense.

my take on .rpm (0)

OklaKid (552472) | more than 12 years ago | (#3710651)

for the most part .RPMs' are great!!!

sometimes I run in to dependency problems, but they are easily resolved, first i make a directory, and put my rpm in it, and go to either or freshrpms and get the required rpm for resolving dependencys, and put em all in this deirectory, then su in a terminal and cd in to this directory, and type in rpm -iUv *rpm and everything is working as it should, then I save this directory in another disk partition if the need ever arises to reinstall the app...

what I would like to see is RPMs become more distro independant so they would work in any rpm based distro, and not be specific to any particular distro...

two tools I use on occasion for Redhat is apt-get for redhat from freshrpms and Ximian's red-carpet they are both good but you gotta watch em close for what they want to do if dependencys crop up or things likethis for example> I recently installed AbiWord-1.02 and then both apt-get & red-carpet wanted to upgrade AbiWord to a older version (0.99 i think)...

so i can sum it up as mostly I like rpm, sure it has a few minor bugs but for the most part they run good enough for me, and I have compiled from sourcecode and could not see any improvment in performance from compiled apps over rpm installs...

perfect, most universal package manager... (0)

Anonymous Coward | more than 12 years ago | (#3710655)

And it is already fully developed:


tar.gz is dying (0)

Anonymous Coward | more than 12 years ago | (#3710659)

tar.bz2 is the new package system that kicks gz of the face of the planet!

My solution: (2)

smnolde (209197) | more than 12 years ago | (#3710656)

... was to migrate to FreeBSD where using cvsup to get updated sources make package managment easy.

There's even a great utility called portupgrade which will do all this for you for installed ports (stuff not in the base system).

RPM and its depends (2)

Indes (323481) | more than 12 years ago | (#3710657)

Ever since Debian started using apt-get and dpkg with deb packages, RPM should have been taken out totally. Programs like apt-get that calculate depends for you and installs those depends BEFORE the actual program makes life much much easier.

So why use RPM. BSD Ports are good. Debian packages are good. Debian can even use alien and rpm to MAKE the RPM into a deb package.

Go Debian!

Re:RPM and its depends (-1, Troll)

Anonymous Coward | more than 12 years ago | (#3710665)

Debian is obsolete and a piece of fucking shit!

Re:RPM and its depends (0)

Anonymous Coward | more than 12 years ago | (#3710726)

But it is stable as hell.

What about up2date? (2)

wfrp01 (82831) | more than 12 years ago | (#3710661)

Nice article, and a good discussion to have. But why was no mention made of up2date - a program designed to alleviate many of the problems with the RPM package format the author mentions?

The primary difficulty I've had with up2date is that you cannot upgrade between distribution versions - e.g. from RH 7.1 to 7.2. Do a dist-upgrade on Debian sometime - amazing!

Debian woody (soon stable) finally provides a respectably up to date desktop environment. Take a look.

Gentoo is a giant step, too long for mere mortals (3, Informative)

isdnip (49656) | more than 12 years ago | (#3710663)

I fully appreciate the author's sympathies. I'm used to replacing RPM-based distros; just last night I burned a new Mandrake Cooker so I could try it. KDE3.01 et al are just too hard to get right using RPM upgrades. But then he mentions gentoo...

...which I have also tried to install. Trouble is, gentoo has *no* installer, past the kernel stage. I can't even get sound to work, becuase my mobo sound chip isn't in their ALSA tree. I'm sure there's a way to do it but they don't tell you. Gentoo users are typically, I suppose, the type of Unix experts who have no trouble figuring out which driver goes where. But gentoo lays things out differently from RedHat (etc.) so I can't just copy their /etc (etc.!) files.

If gentoo had a decent installer, not necessarily as "friendly" as Mandrake (more flexibility is a plus) but which could guide all the files into the right places, then it might be a killer. For now, it's a cult for experts. But I don't see why a binary-based (or at least partially binary-based) distro couldn't use an apt-get or portage-like system when needed, without requiring gentoo's exceptional knowledge (well, that's what it feels like to the "n00b" whose recent Linux experience is mostly RH and Mdk) of the distro's layout.

Re:Gentoo is a giant step, too long for mere morta (3, Interesting)

handsomepete (561396) | more than 12 years ago | (#3710695)

There's been quite a discussion on the installer issue in the Gentoo forums (the thread can be found here [] ). The general consesus from the users seems to be that they like Gentoo being kind of a "niche" distro. If the idea of the source based distro really appeals to you, I would suggest giving it another go and leaning very heavily on the forums (if you need to). Gentoo's Forums [] have the most helpful and friendly user base I have ever seen on the internet. I have yet to see a single person give a n00b a hard time (outside of the occasional rtfm...). I realize that it's not for everyone and that it takes a little bit of work, but I think Gentoo is definitely worth it after the dust settles. It's nice to install an OS and feel like you actually accomplished something.

Oh yeah, and I don't like RPMs.

Re:Gentoo is a giant step, too long for mere morta (2)

mindstrm (20013) | more than 12 years ago | (#3710706)


Look A basic install, though perhaps not quite as bare as gentoo, is really bare. Really light.

You end up, with a minimal configuration, with teh bare minimum you need to boot, get a console, and install more packages over the network.

Then it's a matter of adding packages as you see fit... which is entirely too easy.

to get here, just skip the package selection and/or task selection (where you choose either individual packages, or in beginner mode, what kind of machine it's going to be, development, server, etc.)

I do every debian machine for every reason this way. I love it especially becaues it leaves me with a light, clean system every time.

One of the reasons behind Gentoo is probably one of the reasons why people used to love Slackware (heh, I guess some still do). Because you had to do things the old fashioned way. Get source, comipile, install where you saw fit. You had to actually learn how things work.

I can say that, in having ot mess with early, early version of linux I learned more about how unix works than any other unix I've used. Having to actually figure out, either by reading, or trial and error, what file goes a LONG way towards being able to work multi-platform.

Re:Gentoo is a giant step, too long for mere morta (0)

Anonymous Coward | more than 12 years ago | (#3710721)

Come to #gentoo on sometime....
ugh...its newbie land

RPM is a POS (-1)

Anonymous Coward | more than 12 years ago | (#3710664)

It creates more problems than it solves. A simple packaging system based on tarballs, a la Slackware, is more than enough in more situations, and doesn't result in the nightmare scenarios caused by RPM.

Death to RPM!

Hints... (2, Informative)

n1k0 (553546) | more than 12 years ago | (#3710668)

From the article...

> On the other hand, have you noticed how hard it is to find Debian ISO images? - I can't believe you've never heard of this place. They've had Debian ISOs since I first learned of them.

I admit,'s ISO download wizard is garbage, but I think they're trying to save bandwidth by having you download what you need instead of the entire ISO (there's no reason you need to install every package in the ISO).


Is RPM doomed? (-1, Troll)

davidsmind (524428) | more than 12 years ago | (#3710672)


depends (2, Insightful)

diamondc (241058) | more than 12 years ago | (#3710674)

I use Debian Unstable at home because I always want the latest and greatest software and I already know how to fix 95% of the apt/deb problems that occasionally happen. At work, I use Debian Stable because I never want to touch the server after it's been configured and tweaked.

The good thing about RedHat and Mandrake to some extent is that they do good testing on the RPMS on the cds. I figure they don't expect people to install some 3rd party RPM off the net.

There is nothing wrong with RPMs. Only packagers. (5, Insightful)

Ranger Rick (197) | more than 12 years ago | (#3710675)

The author mentions, "On the other hand, have you noticed how hard it is to find Debian ISO images?" Yes, Debian is very upgradable, but that has nothing to do with the percieved shortcomings of the RPM package format.

The RPM format is nearly identical feature-for-feature with Debian's dpkg. RPM's upgradability has nothing to do with technical issues. There are three things that make Debian's package management so much better than RPM-based distributions.

The first is, there are way more distributions based on RPM packages than deb's. It's not suprising that some of them are more incompatible with each other than any debian release has ever been. Sure, there are many more people with hairy backs in the US than there are in Lichtenstein, that doesn't mean that living in the US causes hair to grow on your back. He is inferring causality where it doesn't exist.

Second, APT. APT is what makes debian's package management so smart, not dpkg. And, in fact, this isn't a reason at all. APT now works with RPM packages [] , and when dependencies are properly configured, it is every bit as good as it is on debian. You can make an APT repository with RedHat's "rawhide" distribution and upgrade daily if you want. You won't have any more upgrade issues than you would running debian unstable. It may break occasionally, but it's when large changes happen. The exact same thing happens on the debian side.

Third, Debian is fanatical about consistency. Most debian packagers manage maybe three or four packages (there are exceptions, of course). When you devote all of your free time to just a few things like that, a lot of attention is payed to details. This is what truly makes Debian's package management so freakin' clean. It has nothing to do with technology, it has everything to do with each maintainer hand-crafting dependencies and build options very carefully.

The thing that pretty much any of the RPM-based distributions is truly missing is the equivalent of the Debian package maintainer guidelines, and a culture that enforces it. If that existed, RedHat would be just as consistent and upgradable as debian.

I use RedHat and I'm careful about what I put on my system, and I never run into upgrade issues. If I'm going to install something that is for a distribution other than mine, I build from .src.rpm's instead of binaries and I *know* it's compatible with my install. Someday, if packagers stop being idiots and using shortcuts, I won't have to. Everything will resolve properly in the huge worldwide-apt-rpm-uber-archive.

Just got ADSL, Just had a nightmare with packages (3, Insightful)

oliverthered (187439) | more than 12 years ago | (#3710709)

I aggree,
I installed mandrake 8.2 a while ago, since then there have been a lot of 1.0 releases out.
KDE (3.0.1)
But mandrakes packages have some rediculios deps, to install KDE 3.0.1 from there cooker(dev), it wanted me to update thinkgs like unixODBC and MYSQl,I don't wan't mySQL and call me stupid but obdc's a protocol!!! and i dont think the latest unixODBC changes that , why the hell have they put such non-granular pagkages togeter, if i had a release plan like that at work I'd probably be out of a job.
The RPM tree locations in mandrake used to be different from the package defaults which ment i could'nt install wines RPM and know i wasn't going to screw up package management some time in the future.

Dependencies of RPM's really need sorting out, and there should be no reason why i can install a suse package on redhat (so long as they both follow LSB!!)


Re:There is nothing wrong with RPMs. Only packager (1)

minkwe (222331) | more than 12 years ago | (#3710755)

Amen to that.

How the heck did he know this? (1)

io333 (574963) | more than 12 years ago | (#3710676)

My jaw dropped as I read this. I've been running Mandrake for over a year now and have been getting SICK of trying to upgrade/install software. What has really intrigued me has been Gentoo. Just last night I was reading through the Gentoo install instructions again thinking: "Wow, do I really want to risk trying to do this on my main (currently dual boot) machine?" Was this just intuition on the part of the author? I find that hard to believe.

You have to ask yourself - where are these users coming from? Gentoo is not easy to install, even with the excellent instructions provided you still need to be pretty familiar with Kernel internals to get all your hardware work. You need to make decisions whether to enable Unix98 PTY support and magic SysRq key, get familiar with Grub and load the correct module for your network card. Surely, a daunting task if your entire previous computing experience was gained from using Windows! Mandrake makes all those tricky decisions for you, Gentoo does not. No, all these new Gentoo users are not users abandoning Windows. They are users who have been around Linux for some time, many of them still have visible bumps on their foreheads. They are ex-Mandrake users, trust me on this one.

Okay seriously. (2, Flamebait)

mindstrm (20013) | more than 12 years ago | (#3710677)

It's about a distribution in general, not the tool.

Roothat is a bloated pig.

Debian is a lean mean fighting machine.

Re:Okay seriously. (0)

Anonymous Coward | more than 12 years ago | (#3710762)

Bloated pig? Ah, another person who has never had the guts or brains to click on "customize" when installing.

Don't blame Red Hat for your ignorance or lazyness.

What about urpmi? (0)

Anonymous Coward | more than 12 years ago | (#3710684)

Its a kick ass tool found on mandrake distros. It uses rpm packages and it finds all the depenancies and installs them for you. Its easier to use than rpm and it graphical rpmisnt utility uses it as well! But sadly mandrake is far too buggy for me though :(.

Re:What about urpmi? (0)

Anonymous Coward | more than 12 years ago | (#3710747)

Obviously you didn't read the article...that option was addressed in it.

The main site & the mirrors (1)

ladislavb (551945) | more than 12 years ago | (#3710687)

The article did not publish the link to the main site carrying the article, so here it is: [] . It's a bit faster than the mirrors.

Why RPM's? (1, Interesting)

Wouter Van Hemel (411877) | more than 12 years ago | (#3710690)

I really hope that plain old source tarballs will stay, I've noticed with recent releases of several software packages, the rpm was released _before_ the plain source, or even only the rpm. It scares me, I really don't want to be forced to use rpms for my system (slackware/linux from scratch). You loose a lot of freedom, deciding what/where/...

I don't understand why people have to offer tarballs, rpm's, deb's, slp's, ... these days. It's a mess, no standards as usually.

Take a look at Ximian's ftp server. For every new version, they have to build specific packages for every distribution, and even every different version of that distribution.

People like me who either like to build from source, or don't have one of those 'supported distributions' - like my slackware and lfs - can't install ximian. Or have to go through hell and back to trick the crap out of the installation-scripts.

I don't want to start a flamewar, but this is not 'free software', if you need specific systems and/or packagers to install it. If it only supports commercial systems like redhat/suse/..., and not me with my little self-made linux system that I made just because of the philosophy gpl-given liberty and the fun of doing it, than it doesn't follow the philosophy I see behind the gpl - or only partially.

Where are the programs? (2, Insightful)

Anonymous Coward | more than 12 years ago | (#3710694)

The first time I installed an RPM which was not included on the CDs, I was wondering badly what happened.

Where was the program?
It was not in the K menu.
It was not on the desktop.
It was lost.

So I thought something went wrong and installed the RPM once more but it claimed the rpm was already installed.

I eventually realized it was indeed installed but the installer did not:
- ask me whether to put an entry in the menu
- decided for itself where the files were supposed to be

Never mind that I wanted the files to be in my home directory.
Never mind that I had no clue what the primary program name was.

There were dozens and dozens of other files in the RPM, mind you. It is not easy to determine what is a binary and what is not when you have just installed Linux for the first time.

And this does not even touch the subject of dependency hell. I have wanted to install several programs only to give up because of a huge number of dependencies.

Backward compatiblity? (2)

k98sven (324383) | more than 12 years ago | (#3710696)

Many of you will have remembered that the RPM Package Manager went from 3.x to 4.x without backward compatibility and upgrading it was an arduous task, to put it mildly.
Aw, it ain't that bad. I found myself changing version numbers in RPMs with a hex editor.

Strangely, it actually worked just fine.

Sometimes I think they break backward compatiblity just for the heck of it.

Well, DUH! :{D (2, Informative)

Gryffin (86893) | more than 12 years ago | (#3710697)

While I agree with the thrust of the article, it would be much more persuasive with a little more meat behind it.

"There is at least one distribution (ESware) that has moved from RPMs do DEBs, but I don't know of any movement in the opposite direction."

A little research into just how many distros have migrated one way or the other in, say, the last five years would be instructive.

"Similarly, there are many users who have moved from RPMs to DEBs, but very few who have chosen the opposite path."

This statement is pivotal to the article, but is completely unsupported by any hard numbers, and comes off overly broad. (Surely there must be have been SOME attempts to determine market share of the major distros?) Maybe you don't know anyone who's gone the other way, but I'm sure it happens.

That said, there's a lotta truth in this article. After a couple years of struggling with RPM Hell on Red Hat and later Mandrake & Yellow Dog, I've recently decided to switch over to FreeBSD (ports, yum!) on my server and Debian on the workstation.

Oh, as an aside, there's an implementation of deb/apt for Mac OS X and Darwin, called fink [] . Fink supports both binaries with apt-get/dselect, and source installs with their own ports-like tool. I know a number of people who run traditional Linux/Unix progs, including X Windows, The Gimp, KDE, etc., side-by-side with their regular Mac apps. Oh so very cool.

Is RPM Doomed?: Morons Please..... (0)

byran lei (517143) | more than 12 years ago | (#3710700)

Does the Apt-Get and the BSD Ports crowd have anything better to do than keep posting these BS articles? PEOPLE WHO USE RPM-BASED DISTROS DON'T GIVE A DAMN WHAT YOU THINK. GET OVER IT.

Source-based and minimalist distributions (2, Insightful)

fw3 (523647) | more than 12 years ago | (#3710701)

I've long preferred slackware for it's approach which basically looks like BSD both for package management and operatoins interface.

For linuxes the various source-based approaches are becoming more popular / solid. In addition to Gentoo, there are Sorcerer Linux and two working forks (Lunar and Source Mage) see summary [] .

As pointed out in a comment above this one, when RPM snafus (often) you can usually build from source with minimal effort. Unfortunatley that's not true for RPM itself, which I have found to be a major pita to build from sources, or things like Gnome / E17.

Vendor unixes (Solaris, AIX, HPUX) put a lot of effort into correctly managing dependency checking. Part of their solution, however is in building their own versions of sources and staying as much as 2-3 years behind the current-releases of any given package.

RPM is a far cry from the vendor unix approaches, part of which I'm sure is that it's trying to do a much harder task on a less well defined base platform (random hardware).

Try building RPM from redhat's sources sometime, use the force you're gonna need it! That alone suggests to me that this is not in 'reality' an opensource project. A GPL license for software that doesn't build with './configure; make' doesn't seem like an effective oss project to me.

RPM haters need to get a life (0)

Anonymous Coward | more than 12 years ago | (#3710703)

My advice would be to the morons who don't like it to come up with their own packaging and see if it gets adopted.

I've had no problem with the RPM package with SuSE, Mandrake or RedHat.

Most problems with RPM are situated between the chair and the computer of the Linux user or the linux developper.

The article is obviously written by someone who dislikes RedHat for some reason or another and needs to get a life.

If Debian was so wonderfull more people would be using it.
The fact that RedHat or similar distributions are more popular should be a clue to the idiots who bitch about it.
Unlike winblows the argument of forced use will not work since none of these distributions are forced down anyone's throat.

Spreading the hatred against RedHat ain't going to make any of us switch to Debian or Slackware. Slackware may be good but it is no good when compared to fancy distributions like SuSE or Mandrake.

I do have Slackware on my computer but only use it to test some stuff. I find SuSE much nicer to use for most of my work in Linux.

Packaging is only a symptom (0)

Anonymous Coward | more than 12 years ago | (#3710708)

Packaging is only the symptom. The problem begins with the design of the system layout or lack thereof (i.e the mimic factor is in place...), the systems Linux ... etc... etc.. are not designed to be installed, upgraded, patched, maintained. These things occured later in the development life cycle. This behavior is the norm in commerical products too

Packaging is mostly a workaround... so what people are looking for is ... the best workaround ... the question that really should be asked is 'how can we design a operating system that is installable, upgradeable, patchable' ...

RPM not the problem.. (3, Insightful)

reflective recursion (462464) | more than 12 years ago | (#3710712)

in itself. The problem is not using the hierarchal file system in a coherent way. In addition to that problem we have way too many files nowadays. When package contents mix with one another.. well I'm sure you've had Chem. 101.

This article wants solutions, so here is mine:
Make packages a seperate directory. Just like good old DOS days--where every program lived by itself in a directory. _All_ package contents go in this special directory. Then you have the problem of per-user configuration. This is incredibly simple. Have a directory in each user's directory which _mirrors_ the package directory. Each package directory should be unique (i.e. MyProgram v1.0 lives in a different directory than MyProgram v1.1). Dependencies would be much easier this way since you would only depend on a _directory_ existing. Moving packages would simply be a matter of packing up the directory and taking it wherever.

In any case, software is _package_ based. Why do we still throw library files from different packages together in the same directory?! When you want to remove a package you have to rely on broken package managers, or hunt down every file which goes with a package. We should be able to completely remove software by simply removing a directory. I've heard MacOS does this, why can't Linux?

Re:RPM not the problem.. (5, Informative)

Fluffy the Cat (29157) | more than 12 years ago | (#3710737)

Why do we still throw library files from different packages together in the same directory?!

Mostly because that's the point of libraries. Libraries allow code to be reused between applications - sticking them in application specific locations makes it somewhat harder for application A to use library B.

Automaticness (3, Interesting)

Apreche (239272) | more than 12 years ago | (#3710715)

What we need is to get rid of the entire packaging system all together. I know I'll probably get toasted for this. But software should install in linux the same way it installs in windows. There should be one file, like setup.exe. I should take that file, execute it, it will ask me what parts of the software I want, and where I want to put it, etc. From my experience there are two pieces of software for linux that do this, the Tribes 2 server, and Mozilla.
The entire packaging system is just a pain in the butt. This depends on that depends on this. urpmi, rpm -i, rpm -U, things not working with no explanation. In Windows I never have to worry about one thign relying on another thing. Because just about everything uses DirectX. And directX COMES WITH anything that uses it. And it has a simple graphical isntallation.
There should be one downloadable file for each piece of software I want. It should install on its own, on any linux machine, easily and graphically. And all of my library packages like glibc, etc. Should transparently update themselves to the newest versions all the time. I dont' want to have to worry about that stuff. Drivers in linux are incredibly difficult to install. They should become a simple right click, install driver. Done. I want all that other crap taken care of for me. I don't have time to change paths in config files, tinker with code, look up crazy commands and recompile crap.
I feel the package system is the real place in which linux fails. Most distros, lets use Mandrake as an example, have graphical easy installations. But when you get to the package selection phase you're stuck forever weeding through thousands and thousands of checkboxes. Not cool.
One piece of software should be one checkbox. KDE alone has like 20+ rpm files. There should be one file. KDE3setup.exe.
You know that installshield that almsot every piece of windows software has? Maybe someone could code that for linux. I would, but I have no idea how to do something like that. But I know someone reading this does. And if you want to save your open source os, I suggest you do.

Problem not entirely RPM's fault (3, Interesting)

Arethan (223197) | more than 12 years ago | (#3710720)

RPM by itself isn't the real problem here. The author is complaining that installing applications in Linux is a pain in the ass, because the system often doesn't have all of the required libs installed.

I admit, RPM doesn't make this an easy problem to solve. Any normal Windows app would simply package the required libraries with it. Thus if the lib doesn't exist, it can install it. But RPM doesn't work that way. RPMs can only hold one logical unit. So one app, or one library, or one set of platform independent support files. RPM builders could include more, but doing so will likely break the RPM dependancy tree.

The real problem in all of this is the destinction between applications and the system itself. Is grep part of the OS, or is it an addon app? How do you tell? Most would argue that grep is a part of the OS, but you can easily install linux without grep, so it must not be essential. But if packages expect it to be there, then it must be essential. But if it's not part of the OS, then they shouldn't have expected it to be there in the first place, so now it is their fault for not thinking ahead... This problem just goes in circles all day. The worst part about this is that my use of grep is just an example. This problem applies to literally all packages outside of the kernel itself. Don't believe me? How about init? Do you think that init is essential? I agree, but what version? Do you want a SysV init, or a BSD style init? Technically you can have either.

To solve this whole problem, we really need to take two steps. First we need to define a base Linux system. And I don't mean a completely solid, unwavering, definition either. Standards that never evolve are quickly dubbed 'legacy'. The trick is to define a complete base install. Everything from the kernel, to the version of GCC (and no RedHat, gcc 2.96 isn't going to cut it), to what version of X is installed, to what "expected unix utilities" are available, and what libraries are available. Feel free to change the standard, but each time you do so you must raise the bar somehow, either by making it more reliable, or faster, or adding features, or some combination of the above. There is only one last key item to making this system work. You must retain backwards binary compatability for long periods of time. Feel free to completely break legacy systems, but make sure that you only do so after you've had at least 5 to 6 years of stability.

Then there is the second step. RPM is a nice system management system, but it is a shitty application packager. Mostly because of the dependancy issues and the fact that each RPM package can only hold one logical unit. We really need an install shield like system for applications (both gui and console installs in the same package). Feel free to keep track of what is installed, and what files belong to who, but you really need to separate the system from the applications. Once you have a base defined, keeping the system and apps under the same packaging system no longer makes sense. The absolute need for it is removed.

RPM is good (1)

Anonymous Coward | more than 12 years ago | (#3710725)

It seems to me that most people that don't like RPM have either not used an RPM-based system recently or simply do not have the proper knowledge on how to use it.

It takes a while to learn to master rpm, yes, but that doesn't mean it sucks. If you don't know how to use RPM, stick to up2date.

I manage quite a few RedHat boxen using only up2date and rpm. It's true that there are sometimes unmet dependencies, but most of the time that is not a problem. If there's a problem it's almost always solvable by checking out

Circular dependencies? What's the problem? Install both (or how many you need) packages at the same time (rpm -Uvh pkg1.rpm pkg2.rpm)
Piece of cake!

Still don't like RPM? Well, apt-get is available for RedHat too, check out

I like RPM. Ignore the FUD.

The problem with ANY packaging system.... (5, Informative)

wowbagger (69688) | more than 12 years ago | (#3710727)

The problem with ANY packaging system is overzelous dependancy definitions.

When Maynard builds his SuperFlyFloobyDust.rpm file, rather than specifying the dependancies as "I need", he accepts the default "I need". So, even though any would work, you get a dependancy failure.

This is a failing not of any specific package manager - ALL package managers have this problem. You don't see it with .debs not because of any inherent superiority of .deb, but rather because of the hard work of the Debian maintainers to make sure the packages are all set up correctly!

Additionally, there is the problem of library makers not following the fscking standards - is SUPPOSED to be fully compatible with - if it isn't, then it should be! However, you get people making libraries that don't follow this rule, so as a result you have to have libNarf.1.[0-99].so in your system because of programs that depend upon their version of that library.

The solution to this CANNOT reside within the package manager - it resides in the distribution maintainer to refuse to deal with packages that break the rules.

However, all it takes is one person installing one program that breaks the rules, and that installation is screwed.

That is where distros like Debian and the *BSD's have the advantage - they are controlled by folks who won't let that happen. However, how many people install from the unstable branches, and why? Because that's where the latest, greatest, shiniest stuff is!

BeOS packaging (1)

Lucky_Pierre (175635) | more than 12 years ago | (#3710734)

Is *MUCH* better, thank you very much!

Nice Sunday Troll (1)

preed-man (1796) | more than 12 years ago | (#3710739)

Thanks "micheal"... you might as well post an "article" called "Is Emacs doomed?" or "Is Debian doomed?"

The author raises some good points and it's not that the discussion shouldn't take place, but the way in which the author has written the article is highly biased and obviously just troll fodder; he's not asking for opinions, he just wants you to read his.

"I hope to get this article on Slashdot or NewsForge..."

He then makes inflamatory statements like "Ask any Debian user and he will shake his head in disbelief that you, as a Mandrake user, have to download 2GB of software every 6 months and then run a risky upgrade just to get your system up-to-date. Silly you!" and " This is the main reason why we have seen so many new Gentoo/Sorcerer users, finally free from the RPM madness!"

Once again, we find the Slashdot editors lacking in any journalistic integrity and asleep at the wheel... and they want us to pay for their incompetence?!

It boggles the mind...

Debian's advantage (1)

spacehunt (6406) | more than 12 years ago | (#3710740)

Debian's advantage lies not in the packaging format. Technically there's not much difference between rpm and dpkg.

What makes Debian stand out is the Debian Policy [] , which all Debian Developers must adhere to. Theoretically someone can apply that Policy to an RPM-based system, and it'll be as stable as Debian.

Why the fuck we have to drag around libraries??? (0, Troll)

Pig Hogger (10379) | more than 12 years ago | (#3710742)

Libraries are the biggest stupidity since Windoze.

It's just as st000p1d as the DLL crap with Windoze. You might have an excuse with proprietary software that's kit-bashed from different sources or of which you may want to update or patch a "feature", but with software of which you have the source, there is NO EXCUSE for that dependency crap.

At least, that's one thing most Macintrash programs have right: no goddam fucking library/DLL dependencies. Everything is in one binary file!

With the big disks we have nowadays and the high bandwidth, there is no reason why you should not be able to include the whole fucking shebang with the application, and keep it isolated (to prevent it from breaking other programs) on your system while you compile it.

My Linux Expiriances... (1, Interesting)

MBCook (132727) | more than 12 years ago | (#3710753)

(Or how I learned to stop worrying and trust apt-get)

When I first tried linux oh so many years ago, I tried THE distrobution (from what I knew) called RedHat. I quickly learned to dispise RPMs, although for a n00b like me they were better than source.

I soon tried Caldera and a few others, I liked RH better, I don't remember why.

Then one day I tried Mandrake. In my oppionion this is a GREAT distro. In fact, it's the one I would use today if it wasn't for RPM. No matter how nice a distro it is, I couldn't stand fiddling with RPMs, downloading everthing I could find and still having it not work.

So I went to another famous distro: Slack. I liked slack alot, especially not having to fiddle with RPMs. Their packages had no dependencies, but they weren't RPMs. I used this distro for a few months, and it was nice, but I wasn't satisfied.

So out of sheer desperation, I tried the ultimate distro, Debian. I had heard it was tough to install. While it was no RedHat or Mandrake, by now I knew quite a bit about Linux and it didn't give me any problems. But what won me over was (like I assume was for so many others) apt-get. You just can't be typing "apt-get install gimp" to get the gimp. All dependencies resolved, all problems taken care of.

Now it's true that Potato (aka Stable) is out of date. It's stable as hell, but I don't think any desktop user should use it (servers are another story, as is often the case). "Testing" has been just as stable for me as full releases of Mandrake and others, that is no crashes. I've never used unstable, but hey, I've got a extra box lying around here somewhere.

So in short all my distro hunting can be put in a few simple steps:

  • apt-get remove RPM
  • apt-get install debian
  • which means...
  • apt-get remove all_problems

This is purely my oppionion blah blah blah....

Debian Fever? (0)

Anonymous Coward | more than 12 years ago | (#3710763)

It seems that the countless hours of using Debian has morphhed this guy into an idiot.

Was this an critical look at RPM or a Debian LoveFest?

All bark, no bite. He whines about problems but offers up nothing to back them up, except of course, "Oh, Debian is a Wonderful distribution!"

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account