“There has been a lot of discussion in the past few months about RPM – its present state, its future plans, and its leadership team. In particular, the Fedora Project has received numerous requests asking us, “what are you guys doing about RPM?” Here is our answer: The Fedora Project is leading the creation of a new community around RPM. One in which the leaders can come from Fedora, from Red Hat, from Novell, from Mandriva, or from anywhere. Job #1 is to take the current RPM codebase and clean it up, and in doing so work with all the other people and groups who rely on RPM to build a first-rate upstream project.”
Isn’t RPM just a package format? In all my years using RPM, I have never had any problems, nor have I ever felt like that I am really missing something. I know Yum is dog-slow but that is a problem with Yum, not RPM itself as evidenced by the speed of aptrpm. I always thought the package is basically “dead” and most interest lies in the actual package managers such as SMART, apt-get, YUM and adding features to them(speed, version control, rolling back, better updating of the system, etc.). Could someone shed some light in this?
Edited 2006-12-14 18:38
Yes is it rpm itself they are addressing or finally a big unified repository or both?
RPM is more than just a package format; it is also the cli tool that (un)installs the RPMs. This is of course also used by all the management apps (like yum). Hence a cleanup of RPM is good for everyone.
All RPM users will definitely benefit from a cleanup, but I’d like to see some features added as well, like dependency resolution ala apt/deb packages.
I know Yum does that, but the repositories are not as robust as I’d like them to be, and it seems to move at glacial speeds. I haven’t tried other solutions, such as urpmi.
They seem to be talking about the RPM program(s) and its development / future. So nothing about building a big unified RPM repository for RPM packages alà Debian’s repos that the all RPM-based distros could use (impossible?), if that’s what you netpython were wondering about?
“Over the past few years, engineers from Red Hat and other companies, as well as a community of independent contributors, have been working on and maintaining their own versions of RPM — sometimes sharing patches, sometimes not. It is important that these contributions move through an upstream process like many other projects do, in order to maintain a healthy community and proper checks and balances.”
Edited 2006-12-14 19:10
Isn’t RPM just a package format? In all my years using RPM, I have never had any problems, nor have I ever felt like that I am really missing something. I know Yum is dog-slow but that is a problem with Yum, not RPM itself as evidenced by the speed of aptrpm. I always thought the package is basically “dead” and most interest lies in the actual package managers such as SMART, apt-get, YUM and adding features to them(speed, version control, rolling back, better updating of the system, etc.). Could someone shed some light in this?
I don’t know what distribution you use, but on Fedora RPM these days barely works, just look at the Red Hat Bugzilla, it has over 100 recent bug reports of RPM segfaulting, hanging, and so on. It has something to do with recently-introduced persistent futexes in Linux, and it’s fixed by the “upstream” RPM of Jeff Johnson, but no distro incorporates that version because of some former disagreement with the author.
Anyways all the “actual” package managers you mention rely on and use rpmlib.
Yes is it rpm itself they are addressing or finally a big unified repository or both?
Only RPM. Big unified repositorieS(!) already exist (for example OpenPKG is rpm-based); but nobody seems to use them. Maybe they’re not such a good idea after all.
… And most of these bug relate to yum problems and not RPM problems.
Someone opened a FUD day and forgot to tell me about it?
– Gilboa
No they might be filed as yum bugs because that’s the command people actually run but the bug is in librpmdb.
I’m not saying the RPM * is bug free. -Far- from it. I am saying that most of the package management problems in Fedora now-days have nothing to do with RPM. (Mostly problems with yum and broken updates)
Either way, I assume that you will agree, that having RedHat/Fedora inject resources into RPM and making it an open, community driven project, is a -good- thing
– Gilboa
* Neither is dpkg/apt. I spent most of last night manually fixing (using dpkg –remove/purge/etc) a botched kernel dist-upgrade that left the machine dead in the water.
Edited 2006-12-16 01:30
I don’t know what distribution you use, but on Fedora RPM these days barely works, just look at the Red Hat Bugzilla, it has over 100 recent bug reports of RPM segfaulting, hanging, and so on. It has something to do with recently-introduced persistent futexes in Linux, and it’s fixed by the “upstream” RPM of Jeff Johnson, but no distro incorporates that version because of some former disagreement with the author.
Do you have any details as to why they won’t incorporate that version? Sounds like a pretty stupid reason not to fix something.
Here is an article about this: http://lwn.net/Articles/196523/
The reason is apparently public sarcasm about Red Hat from Jeff…
And here’s a page comparing Jeff’s rpm to the one currently in Fedora: http://fedoraproject.org/wiki/rpm-devel
That all distros got together over a single package format, namely apt-get with any improvements (if there are any) brought in from the likes of RPM.
Sad but true, Linux and FLOSS could really learn from Apple and Microsoft when it comes to packaging software.
Apt-get is not a package format, it is a package manager.
“Sad but true, Linux and FLOSS could really learn from Apple and Microsoft when it comes to packaging software.”
And what does Linux have to do with package management? Package management is an important (perhaps the most important) task of distros. The kernel has nothing to do here. Nothing prevents someone to create graphical installers like you see on Windows world. The question is: is that The Best Way To Do It (TM)? I don’t think so. Debian .deb package is an excelent example of how things should be done. Is not perfect, of course. But there’s surely no perfection in Apple’s and Microsoft’s packaging methods. All of them have pros and cons. But I think .deb is better, IMO.
Full ack.
That all distros got together over a single package format, namely apt-get with any improvements (if there are any) brought in from the likes of RPM.
They did. The LSB established RPM as the de facto package format for compliant distros. Debian was part of that committee.
At any rate, there are several issues being confused. Package formats, package management tools, and distro package management infrastructures. RPM’s can be converted to debs and installed on Debian. Apt-get can work as easily with rpms as with debs. And RPM (or dpkg) alone as a de facto package manager doesn’t solve the fundamental differences among how distros layout their directory structure and even their own package naming conventions/versioning when it comes to dependencies etc.
Deciding on a format isn’t the problem, it’s trying to convince the distros to make any necessary infrastructure changes to accomodate it as a universal solution.
Sad but true, Linux and FLOSS could really learn from Apple and Microsoft when it comes to packaging software.
I’ve always thought that Apple and MS could learn a lot about the benefits of centralized package management and shared libraries.
And RPM (or dpkg) alone as a de facto package manager doesn’t solve the fundamental differences among how distros layout their directory structure and even their own package naming conventions/versioning when it comes to dependencies etc.
But why should a package be concerned about things like the layout of the distro?
Just have an xml file (say ‘files.xml’) in as part of the package that describes each file and says things like ‘this file goes in whatever directory the distro’s library files are in’, and then let each distro and its own package manager worry about where to put the files and what to name the package?
Then, you could have another file called ‘dependencies.xml’, that describes all the dependencies for the package. Then each distro package manager could decide whether it wants to resolve the dependencies or not. The sky’s the limit
Err never built an rpm have you? That’s exactly what the %files and Depends: directives in the spec file are for. And here you are wanting to introduce freakin xml into the mix?
… Please help me here.
How exactly does your package register a service in say, Slackware vs. Fedora?
Or, how does it restart a service once the service is updated?
What about the kernel? Do you plan to edit lilo/grub/uboot yourself?
What about modular X vs. monolithic X? I do you propose we handle that?
I’d suggest you create a package or two, either for Debian or Fedora/RedHat/SUSE; play around with pre/post/etc scripts -before- you start posting about how a package could be distro-agnostic.
– Gilboa
* Hint. For unified package, you’ll need a standard unified (distro-based) API that each distro must support (and export).
Last time I checked, LSB called it… RPM.
Edited 2006-12-15 18:18
… Please help me here.
How exactly does your package register a service in say, Slackware vs. Fedora?
Or, how does it restart a service once the service is updated?
What about the kernel? Do you plan to edit lilo/grub/uboot yourself?
What about modular X vs. monolithic X? I do you propose we handle that?
A package doesn’t do any of this stuff … that’s not a package’s job. A package itself is (or should be) really little more than a zip file with whatever information is needed to describe files and where they go, along with dependency info and whatever else you need.
It is really up to a distro’s package manager to decide specifically where files should go and what scripts need to be modified on that particular distro to make the whole thing work.
Sorry, but you seem to know little about the complexity of software packaging.
You assumption that the OS package manager can possibly know the
pre-requisites and special configuration of each and every 10,000 packages
that it might handle is absurd. (Let alone that fact that the package manager
might be required to install 3rd party or proprietary packages that it was never meant to
support)
Only the packager knows how the package is built and what the package
requires (both dependency-wise and configuration-wise) and who the package
integrates into the distribution.
I -would- really suggest you examine a couple of packages (KDE, GNOME, kernel,
etc) before making such bold assumptions.
– Gilboa
im not sure sure how much there is to learn.
apple and microsoft makes it simpler by allowing the individual program to pack its own versions of the different libs it uses. this makes distribution of software simple in that you just have to download one self contained file most often.
for open source based programs that will just waste space as most use the same libs anyways. this also benefits security as when there is a exploit found in a library you only have to update one time to fix the problem.
however, i can see a compromise. a kind of meta package. one that contains not only the individual program or lib, but each package needed for installing said program.
then you get the ease of distribution in combo with the security of a single lib, because even if the lib package is included in the meta package, it do not have to be installed unless its a more recent version then the one already installed, or the lib is not already present.
but i wonder, does rpm allow for different versions of the same package to be installed at the same time? as that is a different, yet related kind of “dependency hell”.
for sometimes when a lib is updated it for some reason breaks compatibility with older versions. so unless all dependent programs are then updated, you may result the install of one program breaking another.
about the only linux distro i know of that allow for this is gobolinux. but feel free to speak up if there are others.
all in all, as always its a question of usability vs security…
but i wonder, does rpm allow for different versions of the same package to be installed at the same time? as that is a different, yet related kind of “dependency hell”.
Yes, and not only rpm, any serious package manager has to maintain several versions of the same package at the same time.
There are three ways I know that this occurs:
* Multiple kernel packages are installed side by side, without conflicting with each other (so you do not “update” your kernel, instead you install a new one and make it default in grub)
* Multiple major versions of some libraries (say libxml) are installed to different slots. So when I upgrade libxml version 1 to a higher minor release, libxml version 2 will not be affected.
* The same package for multiple architectures can be installed. This is required on 64/32 bit hybrid systems (SPARC, x86-64, etc).
Of course this list may not be perfect, but this is what I observe on my Fedora systems.
Basically all these could be solved with not using multiple versions of the same package but using multiple packages. That’s what Debian does for the kernel and libraries ([part of] the version is part of the package name).
As for multiple architectures Debian doesn’t use this “solution” but there is no reason why it couldn’t.
Of course, RPM supports multiple versions of the same package even if both contain the same file(s); and that’s something I wouldn’t exactly call a feature.
Sad but true, Linux and FLOSS could really learn from Apple and Microsoft when it comes to packaging software.
Are you kidding? Did you ever try Debian or Arch Linux? Or on the other hand, did you ever install software on Windows?
I found all the install shield crap under Windows was _really_ nasty and disturbing. Windows constantly has problems with overwritten DLLs and needs bullshit tricks like permanently copying system files over on boot etc. to remain stable.
With “FLOSS” – wether under Debian or Arch – I just type in the name of the app I want and do _one_ click / enter key press! I don’t download stuff, I don’t click Next, Next, Next, the uninstaller doesn’t uninstall every file touched while installation, …
I also like the Mac OS way, but only a little bit. At least, apps are easily (un)installed in a clean and unified way.
Having all the libs being maintained and updated seperately gives many features and I wouldn’t want to abstain from this powerfull package management.. but it seems to be nearly impossible to do this with proprietary software.
The problem I see with Windows and software installations is how just installing something can scar your Windows system for life. Take AOL for instance. I mean, it’s almost impossible to get rid of that junk after it’s installed. Oh I’m sure someone could do it, but Windows is such a black box as far as I’m concerned that it’s next to impossible. Linux on the other hand, you always know where you stand with something like rpm, or manually installing something into opt or what have you.
Really?
What package format do Apple and Microsoft use, then?
What’s Microsoft’s package manager? Add / Remove Software? Oh, yes, THAT paragon of reliability, functionality and usability.
/+1.
You’re wasting your time.
If I could zap each poster that posted something stupid in the last 24 hours, the world power usage would have doubled.
How can you moderate a post(er) that doesn’t seem to know the difference between RPM/dpkg and apt/yum but flames away? Off-topic? His stupidity offends me?
How can you moderate a post(er) that doesn’t seem to know know the difference between software based installers (installshield/wise/MSI) and OS based package managers (emerge/dpkg/RPM/etc)?
Sigh…
– Gilboa
Gentoo users might disagree with you there :/
with RPM in the past, as package database corruption, dependency hell, etc. Are all this problems already a thing of the past? If not, I don’t really get how people could live with it when installing new applications and finding they’re still missing some libs. It’s the thing that motivated me to move to Debian years ago.
How are things doing today for Fedora/Red Hat users with RPM?
I think you do not understand how “dependency hell” occurs. RPM as package manager was not designed to solve dependencies while urpmi, yum, apt-get and smart are. In Debian term, it is like complaining dpkg cannot solve dependencies since it was not designed for that task (apt-get is).
As a Fedora users, I report no problem using RPM. At least there are three package managers that suit users: yum which is the default, apt-rpm which use yum configuration and smart.
Edited 2006-12-14 19:26
“I think you do not understand how “dependency hell” occurs. RPM as package manager was not designed to solve dependencies while urpmi, yum, apt-get and smart are. In Debian term, it is like complaining dpkg cannot solve dependencies since it was not designed for that task (apt-get is).”
If I do a dpkg -i somepackage.deb it will complain if dependencies are not met. Dependencies are specified in the .deb package, so when you do an apt-get, the needed packages are downloaded and installed. What I meant to ask was if RPM has dependency information within the package, as .deb has. Last time I used Red Hat was around 1999, so I don’t know how things work now, just that I have that old feeling of things breaking when rpm corrupted its database (was that bdb?).
RPM does so to. its why urpmi, yum and the rest can work at all.
thing is that RPM on its own can not go out and look for packages from external repositories.
but neither can DPG, thats why apt-get exists…
“If I do a dpkg -i somepackage.deb it will complain if dependencies are not met. Dependencies are specified in the .deb package, so when you do an apt-get, the needed packages are downloaded and installed. What I meant to ask was if RPM has dependency information within the package, as .deb has. Last time I used Red Hat was around 1999, so I don’t know how things work now, just that I have that old feeling of things breaking when rpm corrupted its database (was that bdb?).”
Yes, RPM has the dependencies listed, and always has been. The problem itself is not RPM, but the manager. Back then there was no front end, yum for example, that resolved all those dependencies, hence the ‘dependency hell’ many of us experienced. dpkg itself does not load the dependencies, but apt will, as will yum.
I think you do not understand how “dependency hell” occurs. RPM as package manager was not designed to solve dependencies while urpmi, yum, apt-get and smart are. In Debian term, it is like complaining dpkg cannot solve dependencies since it was not designed for that task (apt-get is).
True that, though it doesn’t help the confusion when rpm refers to both the format and the package tool. I think the other problem is that people equate dependency hell with rpms when really a big part of the issue is adding third-party repos that don’t properly align their own dependencies with the core distro repositories, or simply incorrectly constructed or poorly maintained packages.
Unfortunately that seems to happen more frequently in rpm distros, one advantage Debian has is their massive centralized repositories. Though I’ve gotten into dependency hell in *buntu from over aggressively hacking my system and mixing repos as well.
Dependency problems are generally a result of poorly managed repos, poorly designed pacakges, user error or a combination of any. The actual package format has nothing to do with.
In all my years of using rpm on various distros, including Red Hat, Suse, Mandriva, and Fedora I’ve never once had a problem with the rpm database being corrupted, aside from Red Hat 7 or so where they had the weird bug where you’d need to remove the .db003 files or whatever once in a while. This isn’t to say that your rpm database couldn’t get screwed up I suppose, but it probably wouldn’t be anything a simple “rpm –rebuilddb” couldn’t fix.
And as for dependency hell argument, stop already. Seriously. Stop. Deb packages have dependencies the same as rpm packages do. I mean, ever try install a package with just dpkg or whatever it is? Without a frontend, such as apt or yum or what have you, that handles dependencies automatically, then yes, you’re going to have to resolve them by hand.
“And as for dependency hell argument, stop already. Seriously. Stop. Deb packages have dependencies the same as rpm packages do. I mean, ever try install a package with just dpkg or whatever it is? Without a frontend, such as apt or yum or what have you, that handles dependencies automatically, then yes, you’re going to have to resolve them by hand.”
Mmmmm… there was no pun intended. I remember when you had to install packages with rpm, and then you had to manually chase all missing libraries from internet. There’s a long time since I don’t use Red Hat, so excuse me if I ask.
I gave up in frustration, with rpm distros, a long time ago. I found “dependancy hell” to be very real.
Maybe dependancy hell is not rpm’s fault, but even when I tried urpmi, I had the same problems.
I found debian to be like a breath of fresh air.
However, that was some time ago. Nearly five years.
and debian fixes the dependency hell problem by way of central management.
introduce third party packages into the mix and im willing to bet that before long there will be some sort of conflict…
As to best RPM-based package management implementations, in my opinion (and as far as I know), Alt Linux http://distrowatch.com/table.php?distribution=alt is perhaps the best. They use APT-RPM (in my opinion better than YUM), so the package management works very much like that of Debian: a good dependency checking mechanism, big officially supported online repositories for packages etc. Too bad Alt Linux seems to be concentrating almost solely on the Russian market.
Another Eastern European Linux distro, PLD Linux http://distrowatch.com/table.php?distribution=pld has quite interesting and advanced RPM-based package managament too, but unortunately the development process of that distro seems rather slow.
the package management works very much like that of Debian: a good dependency checking mechanism,
Basically RPM dependencies are of the form (say) “libfoo.so.5” while DPKG dependencies are like “libfoo-5.0 package”. So when multiple implementations exist for anything DPKG-based package managers have to invent “virtual” or packages like “foo-handling-library” and make that a dependency and record that implementations “provide” it.
Whereas with RPM none of those workarounds are needed. In my oppinion it’s the sign of a correct design.
As for YUM and APT, they are a different matter. I never really needed such a tool on an RPM based distro (or Slackware) though; whereas on Debian one can’t live without it: Because the way DPKG dependencies are recorded.
[By the way Mandriva/Fedora/SUSE/etc also have big officially supported repositories…]
I’ve always found urpmi to be a fantastic package manager. Everyone is so hung up on apt-get (with good reason) that they tend to forget about urpmi, which I think is a shame.
I don’t like some of the things that Mandriva/Mandrake has done, but their package manager is great. I’ve never been a fan of yum, but it seems to (very slowly) get the job done. I have only used Smart sparingly and therefore hesitate to put forth an opinion on it, but it definitely gave a good impression in my limited use.
I’m looking forward to this, especially if they actually can get input from the “big boys” so to speak.
I know that people rave about apt-get, but rpm has worked pretty well for me. It’s not as fast, but it gets the job done.
I see that many people complain about rpm, but I believe it has room for improvment and that it can reach the level of deb packages.
Good to know that Red Hat is willing to colaborate with the other rpm players there!
It’s actually not Red Hat collaborating with other RPM-based distros but more like all RPM-based distros (with Red Hat at the front) hijacking the RPM project from below it’s original author who still develops it.
I have read some blurry rumour on LWN about some argument between him (Jeff Johnson) and Red Hat but I don’t exactly know what happened and Red Hat’s response seems like a shady move and this is from a Red Hat user.
I like my Debian based distros… I have tried the others, and Debian Based (ubuntu, which is my current) are right where I like to be.
That being said, I am left with enough things I want to try that there are no debs for, and that arent in my repositories, that I sometimes have to alien an RPM and make it work.
I think there should be something like apt-etc that can tie in to rpm or debian repositories, resolve conflicts and adjust packages with alien to make them appropriately compatible.
Give me the ability to use the best of both worlds in one place, and that will be the ultimate package manager.
..then again it would probably create a very easy to break distro.
Actually, I’ve heard so many times that the .deb/apt/dpkg way of doing things is superior to rpm and friends. The internet has quite a few corners where new Debian enthousiasts explain why rpm is bad and how Debian does a better job.
Let’s say for the sake of argument the latter is true. Now, assuming the package management is a very important part of building a binary distribution, if rpm is beaten by dpkg, a distro built with dpkg must have an advantage over a distro built with rpm.
Then, why don’t the binary distros simply adopt dpkg?
Or would that be too much work?
More work than reforming rpm?
Or isn’t dpkg really that superior to be worth the trouble of switching to it?
Why did, in the past, Suse, Mandriva, and others adopt rpm and not dpkg?
Or is it about politics and it looking uncool to have to admit that the package manager you’ve been using for ages is less powerful?
Just a few curious questions by a relatively ignorant.
For the record, I’m just a happy rpm+yum user (yes, very slow), but I wouldn’t go out in the streets protesting if it turned into dpkg all of a sudden (nor am I against binary package management variation).
Side note:
You can make yum just as fast as apt-get by using yum-metadata-parser and yum-fastestmirror. (Just type yum install xxx xxx)
At least to my eyes, yum running on my FC5/6 workstation are almost as fast apt-get on my Debian VMs. (apt-get is still faster – mostly because Debian has local mirrors here in Israel)
As for the rest, I believe that diversity is a -good- thing. Even if dpkg (by
itself) is better then rpm, and apt-get is better then yum, I rather have two
project striving to beat each other, then have a single project full of
compromises.
(Same goes for vi vs. emacs; GNOME vs. KDE vs. XFCE vs. E17; AMD vs. Intel
and… Linux vs. BSD vs…. Windows
)
– Gilboa
RPM was the reason I moved to Gentoo and have never looked back. I am sure it’s better now than the old days but I don’t care anymore. 2c
No, as far as package management goes, current rpm based distros aren’t much different from the “old days”. Red Hat certainly had up2date when Gentoo first came out. Conectiva had apt. Suse had yast. And Mandrake had urpmi. An unwillingness to learn the ins and outs of rpm based distros is hardly a reason to switch to another distro in my opinion. That said, Gentoo certainly had it’s appeal and I can’t say I haven’t had a few Gentoo systems going in my day. But these days, as far as staying cutting edge goes, Gentoo seems to be seriously lagging behind as compared to distros like Fedora and Opensuse. 2c.
But these days, as far as staying cutting edge goes, Gentoo seems to be seriously lagging behind as compared to distros like Fedora and Opensuse. 2c.
Just curious where is it lagging?
can’t be the documentation.
can’t be the hardened project,no other linux distro offers you the possibility of enabling all possible Grsec+PAX features and having Xorg7.x working (nv).I would say that’s pretty cutting edge.
can’t be the package manager
Edited 2006-12-15 05:48
Well, granted it’s been a little while since I’ve run a Gentoo system. In fact I probably won’t again till their darn installer finally works with my SCSI RAID setup (yes my home desktop machine is that nuts). Anyhow, last I checked, gcc was way behind, not even on version 4 yet. The kernel was way behind, etc, etc. It had seemed like they’d lost the manpower or something required to stay as cutting edge as other distros were. But hey, if Gentoo floats your boat, don’t let me stop you.
By the by. Any distro certainly does offer the possibility of enabling Grsec+PAX features and having Xorg 7.x working. This is Linux we’re talking about after all.
By the by. Any distro certainly does offer the possibility of enabling Grsec+PAX features and having Xorg 7.x working. This is Linux we’re talking about after all.
Yes in theory everything is just 1 or 0.
The problem is that xorg has either to be statically linked or dlopen() has to be used which does gentoo by default.It could be much more troublesome to get a binairy distro crafted this way.
Mmmm… seems awfully like an invitation to a pissing contest, but why not?
My current Gentoo (testing) setup includes:
kernel 2.6.19.2
linux-headers 2.6.17.2
KDE 3.5.5
gcc 4.1.1
glibc 2.5
Gnome 2.16.3
Openoffice.org 2.1
Firefox 2.0
Mkay, perhaps that wasn’t the point, but did you mean that the package-manager was lagging? I’d say Portage is the most sophisticated package-manager out there, because it manages a much more complex set of metadata: not just dependencies for successfully running the package, but those for building it as well.
Speed? Well, let’s be honest it’s never gonna install things as quickly as RPM. But! If you compare the packages in terms of the real gruntwork (dependency mapping, querying the package DB etc.) I think it gives others a run for their money. When I moved from Mandrake 10.1 (urpmi/rpmdrake) to Gentoo 2005.1 (portage v1.x) it probably was slower, but the speed-increases with the 2.x series have been enormous.
I also seriously doubt there’s another manager that touches portage for platform-portability (not just architectures; it’s ported to MacOS and Debian among others) and sheer bonkers tweakability. There’s also a good and ever-growing constellation of addons too, such as the excellent equery, and compiler enhancements like ccache and distcc.
/Phew! I rest my case m’lud.
I definitely prefer Slackware’s *.tgz and ArchLinux’s *.tar.gz packages over both *.rpm and *.debs. Trying to crack open an RPM to look at a file inside the package is way more difficult than it needs to be, and the same thing goes for debs (I think, a bit hazy on that).
Hmm. Me, I just fire up file roller or something. I wouldn’t exactly call that hard.
‘Cept I’m a command line junkie – for Arch and Slack it’s just a tar -xzf to get inside. RPM, I need to use rpm2cpio, and then whatever the heck the cpio inflating tool is.
Not sure about rpm, but with Deb packages you can just use dpkg -c (usually piped through more) or you can extract it with dpkg -x. Dpkg actually supports bzip2 now for it’s compression as well as the age old tar.gz.
As far as the two package installers go, neither of them at their base will automatically solve your dependencies, but they do have the information. As a break down you have this;
RPM: Dependency bonus here is that it will depend on either a package name ‘libfoo5’ or library name ‘libfoo.so.5’
DEB: Depends only on package name.
Package Management;
RPM: No standard package manager. This all depends on what Distro you’re running, whether it’s urpmi, yum, yast, zmd, etc. urpmi worked great, as long as you didn’t try to go to Cooker, or use a lot of non Mandrake/Mandriva repositories or packages. Yum is slow, everyone agrees with that, though I think the main reason is because people don’t set a specific mirror, it randomly chooses one (much like Gentoo), which not all mirrors are created equal. Yast, I haven’t really used, but have read that it runs great, and zmd… again haven’t used, but have heard that it stinks something fierce.
DEB: Standard Package manager (Apt, with various frontends that talk through apt.) This is the Plus for DEB.
Third party Packages: I think RPM wins here. Simply because Red Hat has been the enterprise standard for a long time, so all the commercial programs are packaged as RPMs, with a few exceptions. Also a lot of free software is also only in RPM format, though this is quickly changing with Ubuntu taking a huge portion of desktop users. A lot of people are using it now to develop free software, which is in turn good of course for everyone.
Multiarch: RPM wins without problems here, since DEB does not support Multiarch yet. As all things debian, they want to do it ‘right’ and there have been many proposals and ideas for it, but it simply isn’t going to make it in there until after Etch. Which means for Ubuntu they (Canonical) are going to have to pony up some cash for some developers to add this to Debian so it can work it’s way into Ubuntu and other distros that are based on the .deb package. Actually I think any and all of the Commercial entities that have a stake in the manner should work on this, including Xandros, Canonical, Mepis, etc.
I think that pretty much sums it up. The main reason I stopped using RPM based distributions is because I was always eventually running into the corrupted rpmdb as well. I tried to rebuild it, tried many different fixes on the net, and it still wouldn’t work, so all package installation was completely borked. This was in the Red Hat 9.x days. I still try out FC about every other release though.
I haven’t really played around with SuSe linux, from the days when it was still a commercial distribution and the only way to get it was to download it via ftp and create your own ISOs. I still remember that the rpm packages for it were only named gimp.rpm, etc. Is that still the case, or did they finally add the version numbers, i.e. gimp-2.2.4_i386.rpm?
I don’t think this is really so much about current deficiencies in the rpm format or rpm tools.
It’s more about the fact that Jeff Johnson, a former RedHat employee, became increasingly difficult to work with, (not to mention abrasive) and then effectively abandoned maintainership of the project.
Fedora is the logical party to step in to pick it up.
Being, ostensibly, a community based project… they’re looking to develop a community around it.
The “news” here is how the RedHat camp decided to address the situation… and the answer is really no surprise.
Edited 2006-12-15 20:06
As some of you may know, some of the people who created RPMs made a company named Rpath and did a new package manager named conary full of extremely interesting features… I think that the future of rpm is conary
for more info:
http://www.rpath.com and http://wiki.rpath.com/wiki/Conary
Conary is already used in Foresight Linux for example