Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

[Julian Gilbey <jdg@debian.org>]

Hi!

On Sat, Jan 04, 2025 at 05:20:13PM +0800, Maytham Alsudany wrote:
> Hi,
> 
> Most of the problems with wording have been fixed, except for the one I
> note below.
> [...]

There seems to be an issue with this patch, and potentially with the
whole Static-Built-Using field syntax/semantics:

> +``Static-Built-Using``
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +This ``Static-Built-Using`` field must list source packages with an
> +"exactly equal" ("=") version relation, which had their contents (like
> +source code or data) incorporated into the binary package during the
> +build.
> +
> +Cases where this field may be used include (but are not limited to)
> +linking against static libraries in other packages, builds for
> +source-centered languages such as Go and Rust, usage of header-only
> +C/C++ libraries and injecting data blobs into code.
> +
> +This is useful to track whether the package might need to be rebuilt
> +when source packages listed here have been updated. This is important
> +to stay ahead of the package failing to build from source (FTBFS) with
> +the updated versions of the listed source packages, or security
> +updates in the listed source packages.
> [...]

> +A package statically linked with the libraries contained in the
> +librust-gtk4-dev and librust-pulsectl-rs-dev binary packages, where
> +the latter is licensed under GPL-3+ (a license that requires full
> +source code to be available), would have these fields in its control
> +file:
> +
> +::
> +
> +    Built-Using: rust-pulsectl-rs (= 0.3.2-1+b1)
> +    Static-Built-Using: rust-gtk4 (= 0.7.3-3), rust-pulsectl-rs (= 0.3.2-1+b1)
> +

Note that these fields refer to version 0.3.2-1+b1, which is a binNMU
version, not a source package version (though it may be the source
package name).  So this would presumably not be acceptable.  But as
the primary purpose of the Static-Built-Using field is to record the
versions of packages used during the build, surely we should be using
*binary* packages and versions in this field, not the *source*
packages and versions?

Here's where this would be relevant:

Binary packages pkg1, pkg2, pkg3 are built from pkg1-source,
pkg2-source, pkg3-source respectively.

pkg1 statically depends on pkg2
pkg2 statically depends on pkg3

pkg1 is at version 0.1.0-1, Static-Built-Using: pkg2-source (= 0.2.0-1)
pkg2 is at version 0.2.0-1, Static-Built-Using: pkg3-source (= 0.3.0-1)
pkg3 is at version 0.3.0-1

pkg3-source is then updated to version 0.3.1-1

This requires pkg2 to be rebuilt against the new version, and a binNMU
is adequate for this purpose, so we get pkg2 version 0.2.0-1+b1, but
we still have pkg2-source version 0.2.0-1.

But now a rebuild of pkg1 is not triggered, even though that may well
be required: pkg2-source is still at version 0.2.0-1, which pkg1 was
built against, but pkg2 has been updated.  (And in the case of libjs-*
packages, I believe that this rebuild is potentially needed: pkg1 may
well incorporate bundled code from pkg2, which in turn incorporates
code from pkg3.)

The only way to get round this in the current setup would be to do a
source upload of pkg2-source with a new version number 0.2.0-2, and
that somewhat defeats the idea of being able to do updates in an
easily automated fashion.


I would therefore propose changing the Static-Built-Using field to use
*binary* packages and versions rather than *source* packages and
versions to fix this.

At present, there are only about 250 packages in testing that use the
Static-Built-Using field, so the impact would be manageable.


But there may be a really good reason to use source package versions
instead; it would be helpful to hear those.

Best wishes,

   Julian