Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using
Hi!
On Sat, Aug 16, 2025 at 07:34:13PM +0200, Guillem Jover wrote:
> 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>.
> [...]
>
> <js>
I should say first that I am not a core member of the JavaScript team,
nor am I even an expert in JavaScript - only a mere novice. But some
of the Python packages I am involved in have significant JavaScript
dependencies, so I have been involved with the JS team over the last
year or so. My coments above are based on my reading of the
situation, though I am not speaking on behalf of the team.
> 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.
That might be the case, but having binaries not working because their
dependencies are not in sync is also pretty bad.
> 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.
That would seem to me to be the correct course of action.
> 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!
Indeed, and that is the current state of affairs. It would be ideal
of binNMUs could be performed for arch:all packages, and I can imagine
other situations where having this facility might be useful. I
imagine that it would not be too difficult to modify the appropriate
scripts to support such binNMUs if it is decided that they are useful.
> In cases of security issues, this also seems like a bad place to be.
I'm not sure how it would be worse than any other setup. For example,
if every package that required libjs-f embedded a copy of it in the
source code, then resolving a security issue in libjs-f would mean
identifying every occurrence of it in the sources in the whole
archive. Or if, instead, we were to insist that app-js-z explicitly
depend on all of its recursive libjs-* dependencies, one would still
need to rebuild them all when building app-js-z and also keep the
recursive dependencies up to date. With increasingly complex and deep
dependency trees, that becomes unmanageable.
> 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?
The current semantics don't allow for the potential for this future
development, and don't seem to offer any other advantage over the
proposed change to listing the binary packages used (except for not
changing the current semantics, and given how few packages outside of
Rust and Go currently use this field, I don't think that's a
significant problem).
> (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 sorry, I don't understand this - please could you elaborate? How
does C/C++ static linking work in Debian? (And please forgive my
ignorance!)
> [...]
Best wishes,
Julian
Reply to: