Source: perl
Version: 5.32.1-5
We're not including the metaconfig (= regen-configure) original tarball
in a consistent way.
We have uscan(1) machinery in debian/watch and debian/copyright
to filter out bin/ and repack to .xz, but it looks like we're not
using that. The filtering was added pretty early in
commit a42e63561fdfa1ed091cabcfe2b176d1bcac33ff
Author: Niko Tyni <nt...@debian.org>
Date: Sat Oct 14 16:06:17 2017 +0300
Add machinery for generating the regen-configure component tarball
We filter out bin/* from the upstream repo with Files-Excluded because
they are generated files from dist sources. The aim is to use the
Debian packaged dist binaries (mainly metaconfig) together with
the unit probes that were taken from an earlier dist version
(possibly 3.5.20).
Later I added the .xz repacking with
commit 6f5580f38188e6b0c9b12c110058c2db758183c3
Author: Niko Tyni <nt...@debian.org>
Date: Thu May 17 21:14:30 2018 +0300
Use xz compression for component tarball
This makes the tarball reproducible
AFAICS the machinery was used for the 5.28 series, but all tarballs
after that were imported as .gz without filtering/repacking.
We need to decide what to do going forward.
Other things being equal, using the pristine .gz tarball from Github would
seem preferrable to me, assuming Github serves it in a reproducible way
(which it seems to do in my quick tests.)
The argument about bin/* being generated files from dist sources is still
true. OTOH looking at src:dist the sources seem to be just small shell
extraction wrappers around the scripts. FWIW if this is a DFSG violation,
it's present in bullseye too (but not buster).
Another reason for the filtering was to make sure we use the separately
packaged dist binaries rather than the ones in the tarball. Clearly
things have worked fine without this safeguard. If it still feels
necessary I suppose we could replace it with some mv(1) dance in the
update-configure-stamp target.
Using .gz tarballs for regen-configure and .xz for Perl itself leads
into some trouble around #898026, but we seem to have managed with
the workaround documented in README.source.
I'm somewhat at loss. While I'd like to drop the repacking, it seems
that keeping it is a safer course to make sure we ship things with their
source.
If we keep the repacking, we should at least add a sanity check to make
sure we don't accidentally import pristine tarballs anymore.
Thoughts?
--
Niko
