RPM 4.10 Release Supports The Tilde, 7-Zip

[89c51]

all i know is that one of them must die. i don't care which or if its both and have something replace them.

FFS how difficult it is to have canonical redhat and all the other distros to seat down and decide on one way of distributing software on linux.

[Teho]

all i know is that one of them must die. i don't care which or if its both and have something replace them.

What do you think that will solve? It's not like the new format would mean that packages for different distributions would work with the other. Even if it would reduce a bit of duplication I don't think that it would change anything much as both projects seem to have only a few active contributors.

[89c51]

What do you think that will solve? It's not like the new format would mean that packages for different distributions would work with the other. Even if it would reduce a bit of duplication I don't think that it would change anything much as both projects seem to have only a few active contributors.

First and foremost it will eliminate any confusion for the new users. Secondly it will make the life of devs easier. Proprietary software will be easier to install. And probably there are other advantages.

As for the distribution i would like a centralized "place" where i can get my software. A unified linux appstore of some sort that even if i end up to the project website i would have to go through the appstore to get what i want (ie. click a link and open the appstore). Options to built from source or use nightly stuff or dev packages are something that i would like to see if technically possible.

The user experience as it is now is horrible.

[not.sure]

In the end if they want to call it "DPM" or "DEM" or whatever is ok with me.

How about DERP.
Incidentally quite suitable, also for some people and comments here...

[DeepDayze]

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.

Arch's PKGBUILD is quite similar to an RPM spec file as well and Arch's build system is straightforward. Debian has a control file that spells out what is required of a package and I concur it is a bit of a mess though but Debian is working on improving APT all the time

[Teho]

First and foremost it will eliminate any confusion for the new users. Secondly it will make the life of devs easier. Proprietary software will be easier to install. And probably there are other advantages.

As for the distribution i would like a centralized "place" where i can get my software. A unified linux appstore of some sort that even if i end up to the project website i would have to go through the appstore to get what i want (ie. click a link and open the appstore). Options to built from source or use nightly stuff or dev packages are something that i would like to see if technically possible.

The user experience as it is now is horrible.

It doesn't do anythign of those. None. It doesn't mean that the same package will run on all distributions as they need to be compiled against the libaries used in the platfrom.
1. The situation would be the same as it is with Debian and Ubuntu at the moment: both use DEB but the packages aren't compatible. Only difference is that they would be even more incompatible between various major distributios.
2. New users would still have to download packages for their own distribution
3. Propietary software vendors would still have to provide different binaries for different distributions (in most cases at least).
4. The packaking would still be done by distributions so there would be absolutely no difference from developers point of view.

Your second point has nothing to do with the RPM/DPM debate. The horrible user experience has nothing to do with this either. The package management is already abstracted using PackageKit and therefor it doesn't matter what package manager backend you'r using and the interface can remain the same. The AppStream project tries to solve it but again it doesn't have anything to do with this.

[pvtcupcakes]

You can do what most Windows app do and package up all the libs that app needs.
Then of course you end up with 50 copies of GTK/Qt/OpenSSL/etc libraries all over the place.

[Delgarde]

First and foremost it will eliminate any confusion for the new users. Secondly it will make the life of devs easier. Proprietary software will be easier to install. And probably there are other advantages.

No, because you're assuming that the package format is the *only* reason why you can't install DEB files on RPM systems and visa versa. Which is nonsense, since both formats are nothing more than an archive with some package metadata associated with it - it's not all that hard to transform one into the other. The real problem is stuff like the names of package dependencies - one one system (regardless of RPM vs DEB), you depend on "libexpat", while on another it's called "expat". Or "node" vs "nodejs", or "node.js". Changing the file format doesn't solve *anything*.

[bachinchi]

How about DERP.
Incidentally quite suitable, also for some people and comments here...

Nice idea!

No, because you're assuming that the package format is the *only* reason why you can't install DEB files on RPM systems and visa versa. Which is nonsense, since both formats are nothing more than an archive with some package metadata associated with it - it's not all that hard to transform one into the other. The real problem is stuff like the names of package dependencies - one one system (regardless of RPM vs DEB), you depend on "libexpat", while on another it's called "expat". Or "node" vs "nodejs", or "node.js". Changing the file format doesn't solve *anything*.

That's absolutely right. And I know you'll all hate me for this, but there is too much fragmentation in the Linux world. Plan and simple. Unstable API/ABIs and LOTS of duplicated work.

[Teho]

And I know you'll all hate me for this, but there is too much fragmentation in the Linux world. Plan and simple. Unstable API/ABIs and LOTS of duplicated work.

Could you enlighten me with some userspace API/ABIs that aren't backwards binary compatible? There usually is a reason why things are done differently in some cases and there are numerous Linux distributions because people are free to make them. As long as all developement happens in upstreams it bit hard for me to see what the problem is. If we take away the communities around different distributions I could see a huge drop in open source developement. The foremost important thing in volunteer open source developement is that people have fun doing it. If working on their small own distribution motivates people then why would we want to stop them? How exactly do these distributions hinder the developement of Linux as a platform? There are only few commercially viable platforms for desktop/server Linux. There a lot more in embedded space where there's very little community involvement and things are mostly run by big companies. So maybe it is time to stop the bitching about the so called "fragmentation" and focus on issues that actually matter? What has the age old debate on DEB/RPM achieved so far? Nothing.