On Wed, 18 Apr 2018 at 14:36:14 +0200, Mike Gabriel wrote:
> On Wed, 4 Jan 2017 13:41:53 +0000 Ian Jackson
> <ijack...@chiark.greenend.org.uk> wrote:
> > But [vendor.series] is quite wrong, because it means that the same
> > source package has different "contents" on different computers.
>
> The source package is always the same. The bin:pkgs' contents is different.
> But that is different anyway, even if built against different versions of
> Debian. You have to rebuild the package for your system anyway, so what is
> your point here? (addressing Ian with this question)
This isn't as clear-cut as you might think. There are two frequently-seen
possibilities for what you think the contents of a 3.0 (quilt) source
package are:
- the upstream source, with debian/ deleted if it exists, the
contents of debian.tar.* unpacked into debian/, and patches from
debian/patches/ applied
(the "patches-applied" state, as produced by dpkg-source -x and
stored in git by git-dpm and dgit)
- the upstream source, with debian/ deleted if it exists, and the
contents of debian.tar.* unpacked into debian/
(the "patches-unapplied" state, as stored in git by gbp import-dsc
and gbp pq)
Based on his work on dgit, I believe Ian considers the canonical contents
of the source package to be the patches-applied state. Developers who
agree with this point of view would say that applying patches is part of
unpacking the source package, and any source package with vendor-specific
series gets different contents depending where it was unpacked, which
seems strange - steps described as "unpacking" are normally deterministic.
Conversely, developers who consider the canonical contents of the
source package to be the patches-unapplied state would say that applying
patches is more like part of the process of building a binary package
(converting a source package into a binary package), which would imply
that a source package with vendor-specific series always has the same
contents (but those contents result in different vendors building different
patched source code).
I prefer to manage the patches-unapplied state in version control,
but despite that I'm not sure that I can disagree with Ian about the
patches-applied state being the "contents" of the package.
smcv
