Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using
Hi!
On Tue, 2025-08-05 at 09:54:35 +0100, Julian Gilbey wrote:
> On Tue, Aug 05, 2025 at 12:48:58AM +0200, Guillem Jover wrote:
> > 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.
See below <js>.
> > 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.
That would be my expectation, yes.
> > _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.
<js>
I've been thinking about the case of packages embedding their
transitive dependencies, and that seems like something we might not
want to support anyway? It feels like it can/will create nightmarish
support scenarios.
Perhaps I did not understand correctly how the direction the JavaScript
team is planning on taking, but if it implies that say:
app-js-z depends on libjs-a and embeds its contents
libjs-a depends on libjs-b and libjs-c and embeds their contents
libjs-b depends on libjs-d and libjs-e and embeds their contents
libjs-c depends on libjs-f and libjs-g and embeds their contents
Then both app-js-z and libjs-a would end up carrying the contents for
libjs-[a-g]. And when libjs-g or libjs-e get updated the whole
dependency tree (not only the leaf packages, such as app-js-z) would
need to be rebuilt! And done in the correct order, otherwise you might
end up with outdated embedded copies.
This would be compounded with libjs packages being arch:all, which
means (currently) normal binNMUs cannot be triggered, and would require
a mass sourceful transition!
In cases of security issues, this also seems like a bad place to be.
So, given that this seemed like the only case where this was initially
a concern (?), and given the above, I'm not sure we might even want to
support this, and thus the current semantics are fine?
(But perhaps I'm missing something or dismissing an important aspect
of this. Perhaps the JavaScript team instead is going into embedding
all transitive libjs-* dependencies in leaf app packages, if so, then
that looks like a similar scenario to what we currently do with C/C++
static linking?)
> > 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.
Ah, right, sorry, this is indeed probably still like a normal build tool
case than embedding actual sources from the tool itself.
> > 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.
Right.
> 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.
Probably a good idea yes.
Thanks,
Guillem
Reply to: