On Tue, May 5, 2020 at 1:33 PM Florian Weimer fweimer@redhat.com wrote:
- Neal Gompa:
In the merged-source world, the packaging is an aspect of managing the software codebase. This is common in Debian and ALT Linux, where the standard practice with their tooling is to fork the codebase and integrate the packaging files into the tree. Changes then are managed as part of evolving the sources, and packaging is mainly touched when preparing to push to build. And for $DAYJOB, I've implemented this model for software that $DAYJOB makes (we use the split-source model for stuff we didn't write).
This is not an accurate representation of what Debian does. The guidelines and tools very much encourage broken-out patches. The representation is slightly different (via the “debian” subdirectory in a source tree), but this does not mean that you can just change files outside the “debian” directory (i.e., upstream sources), build the Debian SRPM equivalent, and have it built.
Debian *does* have this merged-source model. There are two variants of this model: * merged source with patch trees (debian 2.0/3.0 formats) * merged source with no patch trees (debian 1.0 format)
There is no singular SRPM equivalent, this differs across variants: * singular source tarball (debian 1.0 format) * source tarball + compressed super-patch (debian 2.0 format) * source tarball + debian folder tarball (debian 3.0 format)
The 3.0 source format is the closest to our model.
-- 真実はいつも一つ！/ Always, there's only one truth!