4 ms·

The reason I stayed with redhat/rpm so long ago was that rpm kept the native upstream source file untouched and pristine (most often a tarball). It was very ea

by throw7 7y ago

The reason I stayed with redhat/rpm so long ago was that rpm kept the native upstream source file untouched and pristine (most often a tarball). It was very easy to see what exactly was being patched and the build process driven by the specfile. This appealed to me as opposed to debian which often would just mash local patches together with the source (I hear debs do have the ability to keep the source "pristine", but for whatever reason dd's didn't usually do that).

somepig 7y ago
This is patently false. Source packages with Debian aren't even a single file. They consist of a pristine upstream tarball, a tarball of a /debian/ directory, and a dsc file that describes the package, including checksums of the two tarballs. The /debian/ directory contains all distro specific patches, as well as build rules (a Make file), and package scripts. It's possible to build a 'debian native' package where the /debian/ directory is bundled up with the orig source, but those are few and far between -- primarily packages consisting of debian-specific scripts/tools.
- wahern 7y ago
  All true. Debian and Debian-derived distributions invariably manage their Debian build rules separately from upstream. In that sense there's little difference between RPM and Debian. However, if as a developer you want to include packaging support inside the project (for your own or your users' convenience), this is infinitely easier to accomplish with Debian than RPM packages. Various aspects of RPM--e.g. spec file template semantics, source and build directory locations--not only assume that packaging is done separately, but make violating those assumptions costly. Whereas Debian package build tools rarely make such assumptions. If I want to add "deb" and "rpm" targets to my Makefile, the deb target is a one-liner that directly invokes a dpkg tool using standard options. Whereas the rpm target may require generating a specfile (because some specfile variables aren't trivial to dynamically evaluate inline, if at all) and source tarball, or to go through additional contrivances to avoid either of those two things.
  - Conan_Kudo 7y ago
    `rpmbuild` has had a `--build-in-place` feature for a number of years (since rpm 4.13.0). With that, you don't need a source, or a tarball, and the actions of %prep, %build, and %install are done from the current working directory. This is similar to what have been able to do to make debs with dpkg-deb.

by throw7 7y ago

somepig 7y ago

This is patently false. Source packages with Debian aren't even a single file. They consist of a pristine upstream tarball, a tarball of a /debian/ directory, and a dsc file that describes the package, including checksums of the two tarballs. The /debian/ directory contains all distro specific patches, as well as build rules (a Make file), and package scripts. It's possible to build a 'debian native' package where the /debian/ directory is bundled up with the orig source, but those are few and far between -- primarily packages consisting of debian-specific scripts/tools.

wahern 7y ago
All true. Debian and Debian-derived distributions invariably manage their Debian build rules separately from upstream. In that sense there's little difference between RPM and Debian. However, if as a developer you want to include packaging support inside the project (for your own or your users' convenience), this is infinitely easier to accomplish with Debian than RPM packages. Various aspects of RPM--e.g. spec file template semantics, source and build directory locations--not only assume that packaging is done separately, but make violating those assumptions costly. Whereas Debian package build tools rarely make such assumptions. If I want to add "deb" and "rpm" targets to my Makefile, the deb target is a one-liner that directly invokes a dpkg tool using standard options. Whereas the rpm target may require generating a specfile (because some specfile variables aren't trivial to dynamically evaluate inline, if at all) and source tarball, or to go through additional contrivances to avoid either of those two things.
- Conan_Kudo 7y ago
  `rpmbuild` has had a `--build-in-place` feature for a number of years (since rpm 4.13.0). With that, you don't need a source, or a tarball, and the actions of %prep, %build, and %install are done from the current working directory. This is similar to what have been able to do to make debs with dpkg-deb.