On Sun, Aug 15, 2021 at 05:52:06PM +0100, Simon McVittie wrote: > On Sun, 15 Aug 2021 at 11:52:21 +0200, David Kalnischkies wrote: > One way out of this would be to say that it is a RC bug for packages > in bookworm to have different contents when built in equivalent > merged-/usr and unmerged-/usr chroots/containers (a higher severity > than is currently applied, which I think would be a "normal" or "minor" > bug for violating the Policy "should" rule that packages should be > reproducible).
> > So, your reasoning is that tooling will help us ensure that packages > > built on merged systems work on non-merged systems? Good! > > This is basically another phrasing of the first option I described above, > I think. Yes. And for the avoidance of doubt: If that is part of the plan I am happy as it is one step closer to upgrade sanity. > > No flag day > > required then, we can just naturally upgrade all systems as they > > encounter the $magic and have new buildd chroots bootstrapped now > > merged instead of enforcing them being unmerged still > > (modulo whatever the implementation itself might be of course). > > If we are going to reach a state where package maintainers can > assume/require merged-/usr (for example being able to drop code paths that > only needed to exist because unmerged-/usr is supported), then we need > some point in the release/upgrade process where that requirement becomes > official - and IMO that point in time might as well be a particular Debian > release, because that would be consistent with the rules we normally > use to drop other code that was historically required but is no longer > relevant, like Breaks/Replaces or workarounds in maintainer scripts. Sure, such a flag day for stuff effecting bookworm+1 is fine, my concern was with the effect the flag day has on bookworm itself, by saying unmerged is not support in bookworm while potentially still requiring such systems to continue to exist [= not option 1] and/or having no facility to upgrade them automatically to stay supported. If it hasn't you can do whatever as far as I am concerned, but that isn't what was said until now (and what you repeat in the next paragraph…). So, yes, your strict speaking: > Strictly speaking, the cutoff in the timeline I proposed isn't bookworm r0, > it's the first time you update from testing/unstable *after* bookworm r0. > > ¹ e.g. Marga is saying in #978636 msg#153 that migration from unmerged > > is not required to be implemented for bookworm [and therefore > > effectively at all] for unmerged to be unsupported in bookworm. > > Well, we have the usrmerge package, so an implementation exists. It isn't > perfect, and I hope that between now and the bookworm freeze, we can get a > better migration path than `apt install usrmerge` as currently implemented > (either in a new revision of the usrmerge package, or elsewhere); but it > mostly works in practice. Yeah, well, that is exactly how I have read and understood the discussion so far which means everyone has to run it manually to upgrade every system, container, chroot, … not recently freshly installed … *urgh* That isn't an upgrade path for me and I can't stand others claiming it would be, which triggered this sub-thread to begin with if you remember… > Doing what usrmerge does from a maintainer script is pretty scary from a > robustness/interruptability point of view. Without my Technical Committee "Upgrades are like sausages, it is better not to see them being made." -- Otto von Bismarck (except he said Laws of course) I know it is a major discussion point in this megathread, but that isn't my field of interest, so I feel not qualified to comment on technical details of the implementation of any plan of /usr-merge itself and happily leave that to experts. All I am asking for is a way that ensures that 99% of systems currently supported as buster/bullseye can be upgraded to bookworm and later to bookworm+1 and remain supported without manual intervention. That isn't too much to ask, is it? :P Heck, if we figured out that this isn't possible with dependencies and/or maintainer script we could perhaps even implement something in apt to ensure invariants like "to be able to upgrade to X, you have to install Y first (here, let me do that for you automatically)". Maybe we should ask an apt maintainer…¹ 😉 But that pre-requires that a plan is made by someone who actually knows how its supposed to work… Julian e.g. proposed a silly one[0] in freeze, but that it is of course not workable to print warnings if huge parts of systems apt runs on (e.g. buildd chroots) have to ignore that warning for years (, can't be automated due to this either) and is as usual 2 years too late. (for at least 6 years now as Marco pointed out. I will let the interested reader do the math on that one…) [0] https://salsa.debian.org/apt-team/apt/-/merge_requests/162 ¹ It is early in the cycle, I can still dream of big features we always want to have after the fact, but never find the time and reason before. Maybe this time… > The reasons Marga is being careful not to mandate any specific > implementation […] I get that, but I am a bit unhappy that carrots (= you don't have to support unmerged anymore) are given out without requiring that there is a (not entirely manual) upgrade path for the to-be-unsupported first. Ideally, that path already exists if you change the default and don't intended to keep the old default working forever but that ship sailed even earlier… Every time an upgrade problem is reported against apt I am telling the maintainer that I can only help them so far as I am not a domain expert of the packages involved and they are ultimately responsible to ensure the upgrade works to be part of the release (= carrot), not the apt maintainers, as it would never scale if the release team allowed them to be part of the release anyhow and left it for others to figure out how to make the upgrades work somehow (it is bad enough we sorta do for key packages as that gives us nightmares like libgcc_s did this time). So how big must a change be that we effectively make upgrades an entirely optional afterthought like Debian did here? Best regards David Kalnischkies
signature.asc
Description: PGP signature
