On Thu, May 29, 2025 at 10:53:20PM +0200, Aurelien Jarno wrote:
> Package: e2fsck-static
> Version: 1.40.4-1
> Severity: serious
> Justification: Policy 7.8
>
> Dear maintainer,
>
> The e2fsck-static package provides /usr/sbin/e2fsck.static which is
> statically linked against glibc.
>
> glibc is mostly is mostly licensed under the LGPL, which requires that
> the full source code of the incorporating binary package be made
> available. According to Debian Policy ยง7.8 [1] such a binary package
> MUST list the glibc source package (and possibly others) in the
> Built-Using: field.
Is there an idiomatic way to automatically determine in debian/rules
what version of glib was used to build the binary package, so the
exact version can be specified in Built-Using? Surely there must be a
standard way to do this, since if it's hard-coded as a constant value,
the probability that this value will be incorrect when future updates
are done, perhaps as part of an NMU, will be incorrect.
Worse, if there is an architecture specific NMU rebuild, the version
used for one architecture might be different than another, which meas
the control file would rapidly become unmaintainable and a complete
mess if it needs to be hard-coded and the maintainer has to manually
update.
For that matter, when we do a source upload, the version of glibc that
might be on a particular build server might be different over time
(for example if FTP Masters takes months to approve a package after we
bump the major version number of a shared library, reasulting in a
"new" package being created which requires manual processing...)
What a mess. Surely e2fsprogs isn't the only package that has this
requirement; is there a stock way to address this?
I will note that this information is already uploaded in the buildinfo
file, and given that we have Debian Snapshots, it's not like there
neeeds to be any special processing to make sure the exact version of
corresponding source will be preserved. So requiring maintainers to
manually update the Built-Using field in debian/control seems to be
hopelessly busy bureaucratic work.
- Ted
