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

[phoronix]

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

While Fedora 34 isn't releasing until the end of April or so, there is already feature planning that has continued for Fedora 35 that will come in the autumn...

https://www.phoronix.com/scan.php?page=news_item&px=Fedora-35-RPM-4.17

[Anvil]

im more interested in DNF5

[uid313]

Which one is better .deb or .rpm?
Why don't we just pick one and use one instead of having both?

[bkor]

Which one is better .deb or .rpm?
Why don't we just pick one and use one instead of having both?

There are more packaging formats than just .deb and .rpm. Both .deb and .rpm are better in some aspects. One might be better in one area, then lack in another area.

For .rpm, the spec files and how they're written, plus how things are packaged can differ quite a bit across distributions (especially macros). For .deb, many use Debian as a base. This gives the impression that .deb is more standardized. Moving from one to another isn't easy, loads of tooling might need to be rewritten. Plus it's pretty critical part of the distribution.

It seems like a lot of work, while I don't really get the benefit. It'll not automatically enable installing a Debian package on Fedora or vice-versa.

[skeevy420]

Which one is better .deb or .rpm?
Why don't we just pick one and use one instead of having both?

Neither. It's .pac.zst

[jacob]

Which one is better .deb or .rpm?
Why don't we just pick one and use one instead of having both?

Each has some features that the other is lacking. Their design philosophy is also different: strongly encouraging a grand unified repository (deb) vs anticipating independent third party providers (rpm).

In practice most users don't need to worry anyway, whichever format their distro uses will work well for them.

[skeevy420]

Each has some features that the other is lacking. Their design philosophy is also different: strongly encouraging a grand unified repository (deb) vs anticipating independent third party providers (rpm).

In practice most users don't need to worry anyway, whichever format their distro uses will work well for them.

All our personal preferences aside, that's the best answer. If you aren't building packages it really doesn't matter all that much...though I find the graphical tools for Debs to be the best out of all of them. When GUIs are a factor, Synaptic is hard to beat.

[jacob]

All our personal preferences aside, that's the best answer. If you aren't building packages it really doesn't matter all that much...though I find the graphical tools for Debs to be the best out of all of them. When GUIs are a factor, Synaptic is hard to beat.

Yes as a GUI Synaptic is the best. On the other hand SUSE's zypper is probably the most advanced package manager anywhere.

[kpedersen]

Upon building them, I kind of prefer source rpms. I like that everything is bundled inside a single archive. Whereas .deb source packages generally consist of 3 separate files.

I also think a single deb repo that has to hold everything is a little short sighted and that rpm is a little better here in that it plans for 3rd party repos. However I admittedly have had more trouble with .rpm than .debs so that added flexibility does come at a cost.

Ports collections are great though (FreeBSD, Gentoo, pkg-src, pacman). Build rules which then grab the actual source code from the vendors websites. I see this as a best of both worlds, even if it does occasionally run the risk of the vendors site going down and you need to track down the distfile.

[jacob]

Upon building them, I kind of prefer source rpms. I like that everything is bundled inside a single archive. Whereas .deb source packages generally consist of 3 separate files.

I also think a single deb repo that has to hold everything is a little short sighted and that rpm is a little better here in that it plans for 3rd party repos. However I admittedly have had more trouble with .rpm than .debs so that added flexibility does come at a cost.

Ports collections are great though (FreeBSD, Gentoo, pkg-src, pacman). Build rules which then grab the actual source code from the vendors websites. I see this as a best of both worlds, even if it does occasionally run the risk of the vendors site going down and you need to track down the distfile.

I've never been a fan of source-based distros or ports collections. The security and stability of software depends not only on its source code, but also the compiler used, its version, the build flags, optimisation options, the version of the libraries it uses, their build flags etc etc etc. With a binary distro, if you trust your distro's maintainers (which you basucally have to no matter what), then you know that the executables you install are those they have vetted and cleared. On a ports-based system where each single machine is totally different, any kind of support, reproducibility or even troubleshooting is next to impossible.