Bug#874663: Document +dfsg as extenson when repacking upstream sources
On Fri, 08 Sep 2017 at 16:10:44 +0200, Guido Günther wrote:
> when upstream tarballs need to be repacked because they contain non-dfsg
> free data appending '+dfsg' to the upstream version seems common
> practice. However some packages append '.dfsg', others use
> +dfsg<number> and there are more formats around.
It's a coincidence that you should mention this today. I've just run
into a situation where routinely appending +dfsg causes brokenness:
* upstream releases iortcw 1.51
* I package iortcw 1.51+dfsg1-1
* upstream releases iortcw 1.51b
* I package iortcw 1.51b+dfsg1-1
* oops! 1.51b+dfsg1 << 1.51+dfsg1, because b << +
* workaround: I had to relabel upstream's release as 1.51.b
This made me think that we should maybe only be doing this when
a *pre-existing* upstream version needs to be repacked. For example,
if foo/1.2.3 is found to be non-free after it is already in the
archive, the maintainer would repack it as 1.2.3+dfsg to get a new
orig.tar for the same upstream version; but when upstream releases
foo/1.2.4, even if the non-freeness has not been fixed, the
maintainer would repack it as 1.2.4 rather than 1.2.4+dfsg.
That would make +dsfg into a temporary hack a bit like the +really
(anti-)pattern, rather than something long-lived that is routinely
applied to upstreams whose release tarballs are not entirely Free
(ioquake3 and its non-commercial bytecode compiler, gcc/make and
their non-DFSG docs, anything that bundles RFCs, etc.).
I notice that make and gcc don't routinely decorate their version numbers
in this way, and perhaps they're right to not do so.
> This would make it simpler for tools like lintian or gbp to detect repacked
> tarballs (in this case we don't want to attach the upstream signature to
> the chages file).
Why would the maintainer of such a package want to (arrange for uscan
to) rename the signature to foo_1.2.3.orig.tar.gz.asc where it would be
picked up by gbp? The signature is never going to validate successfully on
the orig tarball, so there is no point in doing that rename.
For repacked packages, if uscan is used at all, it would seem best for
debian/watch to instruct uscan to download the signature, use it to
verify the non-repacked tarball, repack the tarball excluding problematic
files, and *not* rename the signature to the name that contains .orig.
gbp won't see it, and is happy.
Lintian can detect that the tarball was repacked by looking inside
at the first few tar members - a repacked tarball is meant to
contain only a foo_1.2.3.orig/ directory (devref §6.7.8.2.4) and
non-repacked tarballs are unlikely to do so. In this case, ignoring
debian/upstream/signing-key.asc for the purposes of deciding whether there
ought to be an upstream signature would seem like a good Lintian
feature request?
S
Reply to: