Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using
On Tue, Aug 05, 2025 at 12:48:58AM +0200, Guillem Jover wrote:
> 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:
>
[...]
> 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. :)
Hi Guillem!
Thanks for this really thoughtful and helpful email.
Yes, indeed; that was obvious! :-)
> 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).
OK. But I can see the JavaScript team moving in this direction over
the forky development cycle, and there it would make a difference.
> 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»).
In this case, I presume that the binary libfoo.a would not list any
Static-Built-Using packages, as these would not be relevant; there
would not be anything embedded in libfoo.a that would require libfoo.a
to be rebuilt when they are updated.
> _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.
Agreed.
> 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.
I'm not sure why one would want to declare Static-Built-Using: yacc; I
presume that an upgrade to yacc is not likely to change the behaviour
of packages that use it during the build, and the yacc code itself is
not embedded into the resulting binary package (as opposed to the code
generated by running yacc). If we're interested in knowing long-term
which versions of packages were used to build a specific binary
package, that's a separate issue, and we could perhaps start keeping
the buildinfo files in the archive rather than throwing them away.
> 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 (?).
Yes; let's say that a critical bug/exploit was discovered in yacc. We
would then need to rebuild all packages that Build-Depends on yacc,
and those are easy to identify.
> > 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. :/
That's good to know. I also doubt there's much local reliance on
those, given how little they've been used within the main archive, and
I expect that anyone who is relying on them locally will be competent
enough to cope with this proposed (breaking) change. I would also
expect that any local users relying on this field would appreciate the
benefit of the changes proposed.
> 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.
If there is consensus on this, then given what you've pointed out
above, we should probably tighten up the wording of the proposal to
indicate that Static-Built-Using should only list packages whose
upgrading should trigger a rebuild of the package, for example
packages whose content is embedded in the resulting binary package.
But the compiler used should not generally be included in this field.
Best wishes,
Julian
Reply to: