Hi Cyril, On Sun, Dec 29, 2024 at 01:06:46PM +0100, Cyril Brulebois wrote: > That puts a requirement on users to catch up with the point release if > they want to keep being able to debootstrap trixie/sid once the removal > happens (again), which can be surprising / a little point of friction, > but that's much better than previous situations (where debootstrap broke > and the fix was only available in proposed-updates). Indeed in that > case, the support side that's much easier (“just dist-upgrade your stable > system”) than what happened a while back (“add proposed-updates, install > stuff from there, maybe get other package updates, etc.”).
It also is where we are already. The original bookworm debootstrap would do "pre-merging" (i.e. set up symbolic links before unpacking .debs) and using that to bootstrap trixie has been broken by changes to base-files. So we already are in the situation where we require users of debootstrap to upgrade to the latest stable point release. I'm not fond of that situation, but I attribute it to excessive, uncoordinated debootstrap NMUs and consider what I am doing here being a cleanup of the mess left behind. The harm has been done before bookworm. I am merely the one trying to contain it. The whole design of containing the symlink creation in base-files had the goal of removing complexity from debootstrap. The road is bumpy (despite being tested extensively) and I think we need another debootstrap patch, but the end result should make debootstrap more maintainable in the long run. > Out of curiosity (and I'm not advocating for or requesting that): how > much of a hassle would it be to just ship the package in trixie? The answer to that question depends on whom you ask. I think it would mostly defer cleanup. In particular, I am not objecting to shipping trixie with a usr-is-merged package. Having attempted removing it now and seen what breaks is what really helped me figure out what needs doing. Helmut
