On Tue, May 5, 2020 at 1:33 PM Florian Weimer <fweimer(a)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
* 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!