Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using
On 2025-08-05 15:32:51 +0200, Fabian Grünbichler wrote:
> On Tue, Aug 05, 2025 at 01:34:19PM +0100, Julian Gilbey wrote:
> > On Tue, Aug 05, 2025 at 12:34:59PM +0200, Fabian Grünbichler wrote:
> > > [...]
> > > > 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?
> >
> > Dear Fabian,
> >
> > Thanks! I don't know about Extra-Source-Only.
> >
> > > > [...]
> > > >
> > > > 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.
> >
> > Ah, interesting. Would one want to/need to automatically rebuild
> > every Rust package every time libstd-rust-dev is updated? (I don't
> > know Rust anywhere near well enough to know the answer to this
> > question.)
>
> yes, that is already happening in unstable (either naturally by incoming
> uploads, or with a slight delay via binNMUs scheduled by the release
> team/Sebastian :)).
>
> in unstable/main, there's currently three versions of src:rustc kept
> around:
>
> 1.70.0+dfsg1-9 (not sure why?)
proton-caller on riscv64 has a Built-Using rustc (= 1.70+dfsg1-9).
Cheers
> 1.85.0+dfsg2-3 (proton-caller in contrib which was not yet rebuilt
> it seems)
> 1.85.0+dfsg3-1 (the current one)
--
Sebastian Ramacher
Reply to: