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

[Daniel Kahn Gillmor]

Control: reopen 993857
Control: retitle 993857 gnupg2: gnupg-module-overview.png is not built from source

On Wed 2021-12-15 23:40:23 +0100, Christoph Biedl wrote:
> Control: tags 993857 pending
>
> Laurent Bigonville wrote...
>
>> Could you please drop librsvg2-bin from the build-dependencies?
> (...)
>
> Comparing the built packages before and after removing that build
> dependency shows no differences, so it should be safe to drop it.

Thanks for looking into this, Laurent and Christoph.

Looking at it a bit further, I'm not convinced that dropping the
build-dep is the right way to go, either for policy reasons or for
correctness.  Looks to me like upstream is shipping a pre-built binary
image, as well as the source for the image.  We should be rebuilding it,
just like we rebuild everything else.

debian expects to build every generated file from source (the preferred
form of modification) and to not re-distribute any pre-built binaries
from upstream.  Consider if upstream were to ship a pre-built executable
as an example that is clearer -- we wouldn't want to redistribute that.

Upstream's git repo also doesn't contain any copies of the PNG, it's
just included in the shipped tarball.  We have a way of tracking how the
PNG is created during upstream's tarball generation process.

Additionally, the .png in question as shipped upstream is misrendered
-- the text labels for many nodes, and for all of the legend are
not placed correctly.  The version built if I use "convert" or "gm
convert" puts the text in the right spot.  Here are is the version
shipped in upstream's 2.2.27 tarball:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg-module-overview.png
Type: image/png
Size: 123361 bytes
Desc: upstream-distributed PNG
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20220108/36066321/attachment-0002.png>
-------------- next part --------------

And here is the version created on a debian unstable system using
imagemagick from the command line like so:

    convert doc/gnupg-module-overview.svg doc/gnupg-module-overview.debian.png

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg-module-overview.debian.png
Type: image/png
Size: 66665 bytes
Desc: debian-generated PNG
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20220108/36066321/attachment-0003.png>
-------------- next part --------------

So the debian-generated image is both more policy-compliant and more
correct.  We shouldn't stop building it from source.

What's the right way to go to build this on systems where we don't have
rust?  Here's one idea (i haven't tried it yet):

- ensure that gnupg-module-overview.png is shipped in an
  architecture-independent package (e.g. gnupg itself, which is an
  Architecture: all metapackage).  This is where it is today, so far so
  good.

- move the build-deps for it (including imagemagick and librsvg2-bin)
  into the Build-Depends-Indep: section

- maybe put those build-deps behind a <!nodoc> build profile flag for
  minimizing dependencies (see https://wiki.debian.org/BuildProfileSpec)

- ensure that the binary packages build cleanly anyway

- ensure that the arch-independent builds actually do rebuild the .png
  (we might need to delete it before the build depending on the
  timestamps in the tarball)

Laurent, would that approach satisfy your concerns on rust-less
architectures?  Those arches could of course install the
arch-independent packages that were built on platforms like amd64 which
have rust available.

hope this is useful information,

     --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/36066321/attachment-0001.sig>