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.) Best wishes, Julian
