On Wed, Nov 10, 2021 at 01:48:07AM +0200, Uoti Urpala wrote: > David Kalnischkies wrote: > > As the transition hasn't started everyone not already merged is currently > > deferring it. That is true for those who upgrade daily as well as for > > those people who seemingly only upgrade their sid systems once in a blue > > moon. So, at which point have all those systems stopped deferring? > > I think the logical answer is that you're "deferring" in this sense if > you are using the suggested flag file or whatever other mechanism to > prevent the merge. Until you do an upgrade which would perform the > merge without use of such a mechanism, your system is just out of date, > not deferring. A distribution upgrade is not atomic. Between an unpack of package foo and the configure of foo a million other packages can pass through various stages. Ideally, that window will be pretty small for usrmerge the package (or whatever the transition mechanism will be in the end), but that depends on various factors and easily balloons out of hand. In a previous thread I mentioned how not too long ago the entire KDE desktop environment had to be at least unpacked before dpkg could be upgraded due to one tiny Conflicts (which was correct). If you hadn't KDE installed dpkg was one of the first things upgraded even without users going out of their way to explicitly request it (as it should be, as its essential and apt does special dances for those). So the easiest way to check if an upgrade on a "quantum state merge" system is going to work is to keep it at unmerged for the entire time and manually trigger the merge at the end as that is what could theoretically happen, but is likely not for most testers. If it works with merged is already checked by already merged systems. > So presumably it is valid for packages to gain dependencies which force > merge or "deferring" state on installation. Valid perhaps, but I would hope that it isn't lightheartedly plastered all around just in case as the guarantees it provides for the package depending on the transition mechanism package are slim (as in, the system might or might not be merged, regardless of deferred or not¹, while depending package itself passes through various stages) to non-existent² depending on the specific implementation of the transition while it puts potentially enormous problems on the shoulders of dpkg and apt to produce an acceptable ordering: The package usrmerge is e.g. currently implemented in perl (the big one, not -base) and so any other package implemented in perl is effectively forbidden from forming dependencies on usrmerge as we otherwise run into loops of the form app -> usrmerge -> perl -> app which might or might not be breakable based on the dependency type (and version) of each ->. Oh, and if you happen to have a dependency on something written in perl, congrats, you are part of this elusive group as well as everything else depending on you… It will be hard enough to have one essential package trigger the mechanism without running into issues, the last we need is a couple other packages inserting themselves needlessly into the loop just because "it is valid". Best regards David Kalnischkies ¹ Spoiler alert: Even a Pre-Depends technically only makes guarantees for the preinst scripts, not for the unpack itself, but that is fine print usually only encountered in the deeper horrors of loops… you need explicit approval for Pre-Depends anyhow. ² Spoiler alert: You can e.g. Pre-Depend all you want on dpkg, but that doesn't mean that the version you are pre-depending on is actually used to work on your package instead of just lying around on disk. That is true for a few other packages, the most obvious perhaps apt and the kernel.
Attachment:
signature.asc
Description: PGP signature