Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using
On Tue, Aug 05, 2025 at 09:54:35AM +0100, Julian Gilbey wrote:
> On Tue, Aug 05, 2025 at 12:48:58AM +0200, Guillem Jover wrote:
> > > 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.
CCing Stefan, who currently schedules binNMUs based on Built-Using and
Extra-Source-Only, IIRC. not sure whether RT already acts on S-B-U
anywhere as well, in addition to that?
> > 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.
note that for Rust, this is for the most part not true - except for
niche use cases (nostd, like when building embedded things or Linux
kernel stuff), the standard library which is part of the toolchain
packages *is* statically linked into any Rust executable. and even for
nostd, the same applies to a smaller standard library (libcore).
so while Static-Built-using rustc could go away following this line of
reasoning (which I do agree with - grave compiler codegen bugs warrant
rebuilding the world anyway), libstd-rust-dev would remain.
Reply to: