[pkg-gnupg-maint] Bug#993857: Bug#993857: Bug#993857: gnupg2: Please remove librsvg2-bin from BD

[Daniel Kahn Gillmor]

On Sat 2022-01-08 21:39:25 +0100, Laurent Bigonville wrote:
> My understanding of the policy has always been that the source tarball 
> shipped in debian must indeed contain all the files in their "preferred 
> form of modification" but the fact that the resulting artifact has to be 
> rebuilt during the build of the package was merely a recommendation.

This is almost certainly not the case for executable code -- if someone
upstream shipped an x86_64 binary, as a debian user i would be pretty
upset if the upstream binary was just passed through directly.

But whether executable code or not, the requirement isn't just that the
source code is available, but that the toolchain is also all free
software, right?  (there may be some exceptions for bootstrapping
tooling, but afaict we're working on trying to fix even that with
diverse dual compiling, rebootstrap, and reproducible builds projects).

The only way that i can see to be confident that the toolchain is
present is to actually do the build, right?  and if we do the build and
it's different than the generated object shipped by upstream, which one
should we prefer?

> My main concern here was to be certain that gnupg can build all 
> architectures even the one without rust support and your proposal allows 
> this, so it's good for me and if you think it's better to rebuild the 
> image during the build I've no objections.

makes sense (and i share your goal)!

> The fact that there is a rendering problem with the .png shipped in the 
> upstream tarball should be reported in any case I think.

Agreed, though i'd just as soon ask upstream to stop shipping the png in
their tarball :)

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20220108/17962259/attachment.sig>