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

[kpedersen]

On a ports-based system where each single machine is totally different, any kind of support, reproducibility or even troubleshooting is next to impossible.

Yeah absolutely. So I shudder at the idea of building *everything* from source yourself (not a good use of energy!). Instead packages are built by the upstream build servers using the ports collection and 99.9% of the time you should use them. This gives you most of the same guarantees on the quality of the final package.

Ports are quite handy when you need to update a single package or modify the build parameters of it. In the ideal world you grab the very latest ports snapshot (instructions / scripts on how to build) and it will compile and link against your currently installed libraries.

I suppose when you think about it, it isn't too different from i.e srpm, source debs. The only difference is it pulls in from the original vendors site rather than the i.e FreeBSD servers. If you got every srpm and extracted it in a nice directory layout, you would have something that vaguely represents a ports collection (with the distfiles).

[pc777]

I personally prefer rpms. Philosophically, rpms are never to touch the original upstream tar ball. I always liked how easy it was to see what the local patches were to build the binary. Debs can be packaged in this way, but it's definitely not how things were done, especially in the early days.

Also, rpm installs were specifically NOT to be interactive ever. I also liked this opinioniated stance.

[tildearrow]

Neither. It's .pac.zst

What distro is that? I never heard about .pac, only .pkg?...

[jacob]

I personally prefer rpms. Philosophically, rpms are never to touch the original upstream tar ball. I always liked how easy it was to see what the local patches were to build the binary. Debs can be packaged in this way, but it's definitely not how things were done, especially in the early days.

Also, rpm installs were specifically NOT to be interactive ever. I also liked this opinioniated stance.

Not quite. Many rpms do apply patches to the upstream sources and sometines that's good.

[RahulSundaram]

Not quite. Many rpms do apply patches to the upstream sources and sometines that's good.

The point is not that RPM packages apply patches but instead that upstream source is clearly separated from the patches within the package.

[jacob]

The point is not that RPM packages apply patches but instead that upstream source is clearly separated from the patches within the package.

same with deb

[RahulSundaram]

same with deb

Not uniformly, no. It depends on what version and system is used and there have been several :

https://wiki.debian.org/debian/patches

[jacob]

Not uniformly, no. It depends on what version and system is used and there have been several :
https://wiki.debian.org/debian/patches

That's the different build chains that have historically been used but there has always been an .orig.tar.{gz|xz|bz2|etc} tarball, and either a .diff.gz to patch it, or (in the modern source package format) a debian.tar.{gz|...} that contains debian/patches.

[RahulSundaram]

That's the different build chains that have historically been used but there has always been an .orig.tar.{gz|xz|bz2|etc} tarball, and either a .diff.gz to patch it, or (in the modern source package format) a debian.tar.{gz|...} that contains debian/patches.

RPM packaging has uniformly maintained a list of upstream pristine sources, followed by a list of *separate patches* in a single spec. That's the difference. For Fedora, you can find it all in https://src.fedoraproject.org/ and the packaging method is consistent and the build tooling is the same across all the packages.

[jacob]

RPM packaging has uniformly maintained a list of upstream pristine sources, followed by a list of *separate patches* in a single spec. That's the difference. For Fedora, you can find it all in https://src.fedoraproject.org/ and the packaging method is consistent and the build tooling is the same across all the packages.

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.