Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using
Hi!
On Mon, 2025-08-04 at 14:40:07 +0100, Julian Gilbey wrote:
> On Sat, Jan 04, 2025 at 05:20:13PM +0800, Maytham Alsudany wrote:
> > 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:
[…]
> 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?
To give some context, the new field came about when concerns were
raised about reuse of Built-Using for the non-license cases. So the
field naturally inherited the previous semantics, just in a different
field. (But I'm not saying this to argue that this is thus correct. :)
> 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.
As has been mentioned elsethread I think currently the main users of
the field involve source based binary packages (similar in nature to
C/C++ header-only -dev packages), where I don't think this would make
much of a practical difference (because pkg1 would list both pkg2-source
and pkg3-source in its Static-Built-Using).
For the static library cases (libfoo.a), I'm not sure this might make
(in general) much of a difference either. As I'd expect static library
packages to only include objects generated from the same source
package (and not from all transitive dependencies), and where the final
executable or shared library (if everything else has been built with
PIC/PIE), then embeds all the static libraries (and where the package
should also list the equivalent of all source packages that provide
libraries from say «pkgconf --static --libs libfoo»).
_But_, in contrast to the license-relevant Built-Using field, where the
important part is the source package (to be kept around for compliance
reasons), if we do really have packages that are to be embedded by
others and that are currently embedding (or might do so in the future),
other transitive static content, then this would be a problem, indeed.
And where using binary names and versions would be better, while this
would not really affect/disrupt every other case listed above.
I'm also thinking that while in general the most important part is going
to be explicit source changes (in a new package revision), that cascade
into whoever ends up embedding that code, there can also be generated
source changes (via tools that generate source from source, f.ex. yacc),
or binary object changes (via tools that generate objects from source,
f.ex. gcc). Where the former would be closer to the scenario that
Julian was presenting, where a package that ends up with compiled
output from yacc in its libfoo.a could declare itself
«Static-Build-Using: yacc (= ...)», but then it would not make much
sense to transitively add that into all users of libfoo.a. But for the
latter I don't think this is a problem, because this would arguably
affect all/most/many binary packages in the archive, including those
not statically linking/embedding, so we'd need some other way to track
what to rebuild anyway (?).
> 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.
Although we have some tooling generating the fields (mainly in the Go
and Rust teams), I don't think there's currently tooling in Debian
consuming the fields yet. But then also, the fields have been documented
with those semantics since dpkg 1.21.3 (as present in Debian bookworm),
so there could be local reliance on those. :/
If there is consensus that we'd want the more precise (although in
many cases possibly irrelevant) information tracking, I'd be fine
with the changed semantics, and I'd be happy to update the
deb-control(5) man pages. Taking into account that while it feels
early enough in Debian terms (given that we currently have no
consumers that I'm aware of), this has the unknown of potential local
users.
Thanks,
Guillem
Reply to: