RPM 4.17 Planned For Fedora 35 With Better Install Failure Handling, Lua Integration

[RahulSundaram]

It's exactly the same in deb. The only case where a deb package doesn't have separate patches is if it's an original piece of software developed by and for Debian (or Ubuntu). For example the source package for dpkg itself obviously doesn't have any separate patches. In all other cases you have an untouched original source tarball and separately maintained patches that are not part of the source tarball.

Not the same thing. diff.gz is a unified context diff from upstream bundled in. There is no machine readable list of patches in that format.

[jacob]

Not the same thing. diff.gz is a unified context diff from upstream bundled in. There is no machine readable list of patches in that format.

That has been deprecated a long time ago. Besides it's kind of nitpicking, because with diff.gz there was only a single patch, no "list of patches". But even then it was clearly separated from the upstream source archive.

[RahulSundaram]

That has been deprecated a long time ago. Besides it's kind of nitpicking, because with diff.gz there was only a single patch, no "list of patches"

Yes, that is precisely my point that it was historically just a single bundled patch, not a list of individual patches, that is a substantial difference from RPM which has always maintained a list of individual patches in a machine readable format. This matters quite a bit when you are trying to understand the differences and want to cherry pick changes as upstream developer or for cross distribution patch sharing which is my direct experience with it.

[jacob]

Yes, that is precisely my point that it was historically just a single bundled patch, not a list of individual patches, that is a substantial difference from RPM which has always maintained a list of individual patches in a machine readable format. This matters quite a bit when you are trying to understand the differences and want to cherry pick changes as upstream developer or for cross distribution patch sharing which is my direct experience with it.

The patches are created by the package maintainer. If the maintainer creates several distinct patches you will have "individual patches", if he or she gobbles all modifications into a single giant patch then that's what you get even with RPM. I have been maintaining deb packages for a long time and recently switched to Fedora, so I learnt to rebuild my stuff as RPM, and frankly it's kinda neither there or there. Each has a zillion features that the other doesn't, but whether they are a good or a bad thing is debatable, which is why I think that there is only one true killer feature that deb has over rpm, and that's ABI tracking for shared libraries (it's limited and technically it's not a feature of the format or package handler but rather of the build linter, but it mostly works and is useful), and only one killer feature for rpm, which is package triggers.

[RahulSundaram]

The patches are created by the package maintainer. If the maintainer creates several distinct patches you will have "individual patches", if he or she gobbles all modifications into a single giant patch then that's what you get even with RPM

While this is technically true, what happens in practice matters and that is often dictated by things like packaging guidelines. You will be hard pressed to find RPM packages including in Fedora that ever had a giant patch in the official repository. This was historically routinely the case for official Debian packages.

To the larger point, they are roughly comparable now because feature cross pollination happened quite a bit over the years but there are certainly individual differences that still matters. For instance, if you are talking about related tooling, yum/dnf history rollback/undo features comes to mind as something I routinely use.

[jacob]

While this is technically true, what happens in practice matters and that is often dictated by things like packaging guidelines. You will be hard pressed to find RPM packages including in Fedora that ever had a giant patch in the official repository. This was historically routinely the case for official Debian packages.

Kernel packages used to have a giant patch (although that was a long time ago).

To the larger point, they are roughly comparable now because feature cross pollination happened quite a bit over the years but there are certainly individual differences that still matters. For instance, if you are talking about related tooling, yum/dnf history rollback/undo features comes to mind as something I routinely use.

I like the rollback feature too, even if it's nowhere as sophisticated as what zypper offers.

[sheldonl]

What about differences in things like the ability to do delta patches and roll backs. I know those exist in RPM's but I don't think that functionality exists in debian based distributions. I know there is a debdelta, but I think it's abandoned and I don't think anyone ever used it. I don't think there has ever been rollback support in debian.

Otherwise AFAIK, both rpm and deb are pretty even in terms of capabilities. Debians big thing used to be apt, but then came urpmi, yum, dnf, etc. If there is anything I think debian based distros have going for them its an extremely large repository and the relatively easy ability for packages to add additional repositories to keep themselves up to date.