Re: Hard Rust requirements from May onward
On 2025-11-04 18:08:16 +0100, Fabian Grünbichler wrote:
> 4) lack of tooling to analyze which packages need to be rebuilt
>
> for binNMUs in unstable, there is drt-tools[2] (which allows scheduling
> transition or ExtraSourceOnly related binNMUs, as well as built-by-maintainer
> ones via excuses). other similar workflows also have tools to assist with
> (re)building. TTBOMK, there is no such tooling for finding out which packages
> (potentially) need a rebuild because of an updated, statically linked package.
>
> I suspect this would not be too hard to write once S-B-U is finalized and has
> more adoption. it would also be nice for unstable binNMUs after non-security
> updates, although at least in the Rust part of the archive those happen
> regularly anyway, triggered by the toolchain's 6 week release cadence.
drt-tools already supports S-B-U. For B-U we already track necessary
rebuilds for stable and oldstable at
resphighi.d.o:~sramacher/nmu-eso-stable and
resphighi.d.o:~sramacher/nmu-eso-oldstable. Starting to track rebuilds
required due to S-B-U would be easy enough.
There are however a few issues that I haven't had the time to work on to
get this fully ready. We currently run into issues with reused versions
as there is no easy/good way to track all used versions. So we had
binNMUs in stable where versions had been reused or which caused prop
ups. Once I have time to figre out how to compute unique binNMU versions
and schedule potentially necessary binNMUs in unstable at the same time,
we should be more close to an automatable solution. (see also [1])
Also, drt-tools does not know about not released stable updates, so it
only check for necessary rebuilds once packages have been released to
stable-security or proposed-updates.
Cheers
[1] https://github.com/sebastinas/drt-tools/issues/14
--
Sebastian Ramacher
Reply to: