* Theodore Ts'o <ty...@mit.edu> [250530 02:15]:
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?
Here's an example I found using codesearch, from the grub package:
https://sources.debian.org/src/grub2/2.12-7/debian/rules/?hl=593#L593
BUILT_USING=$(shell dpkg-query -f '$${source:Package} (= $${source:Version}),
\n' -W liblzo2-dev)
...
override_dh_gencontrol:
dh_gencontrol -- -VBuilt-Using="$(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.
Please don't manually mantain a field in the source package's
d/control that's supposed to exist only in binary packages.
Chris
