If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

There are 0 reasons to have both RPM and DEB systems. Just a mess for maintainers with no real advantages for end-users in having one instead of the other. If there were real advantages of one over the other, then just adopt the best one. Instead no, we have to have 2 systems just for the glory of uknown anti-end-user reasons.

To make it short: We all know DEB is better than RPM, the problem is that Red Hat, the biggest commercial Linux solution, for historical reasons uses RPM. And for this reason, we still have RPM. I call this an issue.

Let's not even mention all the other packaging systems. Each of them says "Hey, mine is better than yours". Sure sure, yours is of course longer than mine. If everyone think like that, today there would be 0 international standards. And this is why I just hate that each "major" distro has its own way of doing its packaging system. Sure, once again, yours is of course longer than mine. They all say the same thing.

Comment

To make it short: We all know DEB is better than RPM, the problem is that Red Hat, the biggest commercial Linux solution, for historical reasons uses RPM. And for this reason, we still have RPM. I call this an issue.

Complex of superiority symdrom from that post. Deb packaging success is mainly due to its policies rather than technical RPM still edge DPKG.
Next time, do a proper research instead of relying to a "holly debian style zealotry" because it is "oh my god, red hat is the devil" style.

Comment

This is just RH acceding to the popularity and technical superiority of apt/dpkg

Bullshit.

What makes deb more popular is the huge amount of work that Debian puts into it. It's brute force that makes it work.

RPM has a number of technical advantages. One of the big ones is that it's designed for unintended installs and updates were as Debs depend on debconf. This means that the _RIGHT_ way to perform automated updates and installs for Debian is to do it all manually a head of time and then setup pre-seed files with the answers you need. This dependence on debconf makes it more of a hassle to deal with then rpm. Most of the time people resort to hacks like reconfiguring cron-apt to install packages rather then just downloading updates for you to install later. I could go on with other examples, but there is no point to it because either you understand at this point or you are not going to care about technical arguments and just blather on about nonsense.

HOWEVER...

In reality Slackware is right. There is no need to have anything much more complex then Slackware's tarball format they use. It's just a tar.gz file with a description file containing metadata about the package. Add the ability to sign files or signed package lists of package checksums then you are set.

Linux distributions depend way too much on package management systems to paper over lack of discipline in userspace APIs. People regularly change APIs for applications which causes breakage during major updates and between releases. There isn't really a good reason why a package from 3 years ago shouldn't work today for end user applications. Distributions just depend on putting significant amount of human resources into solving API/ABI breakage issues and this means that resources are tied up on duplicate efforts instead of bug fixes and improvements.

In reality distributions should NOT be packaging software, except for 'core linux' stuff and software developed by the distributions. Software packages should be built by developers and those packages should be gathered up by distributions for their package repositories. Gnome packages should be built by Gnome. KDE packages should be built by KDE. XFCE should be built by XFCE.. Games built by game makers. Chrome built by Google, etc etc. Then distributions just pull in the packages they want for their repos.

All in all for end users this means that IF the software they want is packaged by distributions then it's great. But if they want to use something that is not built specifically for their current version of their OS then it's a PITA.

Comment

In reality distributions should NOT be packaging software, except for 'core linux' stuff and software developed by the distributions. Software packages should be built by developers and those packages should be gathered up by distributions for their package repositories. Gnome packages should be built by Gnome. KDE packages should be built by KDE. XFCE should be built by XFCE.. Games built by game makers. Chrome built by Google, etc etc. Then distributions just pull in the packages they want for their repos.

And you pretty much kill the concept of "distribution" in there ... because you're omitting A LOT of variables

Comment

I'd take rpm spec files over the mess that is the debian build system any day. The macros are very useful and standardized albeit there are distribution specific options, such as for build systems. The syntax is not bad either. All in all, rpm follows a fairly principle of least surprise approach and lets you build software properly for a distribution in a manner that doesn't involving throwing away more time than you should have to.

So here's why rpm should win: Quicker, cleaner, and leaps and bounds more straight forward (especially in organization). I do hate needing to use cpio to extract an rpm though.

Comment

To make it short: We all know DEB is better than RPM, the problem is that Red Hat, the biggest commercial Linux solution, for historical reasons uses RPM. And for this reason, we still have RPM. I call this an issue.

Do you have any reasoning for this, or are you pulling this out of your ass?
You sound like a fanboy.