Hello, On Mon 27 Sep 2021 at 10:59AM +01, Simon McVittie wrote: > On Thu, 16 Sep 2021 at 15:35:11 -0700, Sean Whitton wrote: >> You write: >> >> >> - Because Debian 11 installations with the non-merged-/usr layout already >> >> exist, all packages in Debian 12 should be installable onto a non-merged-/usr >> >> system along with their dependencies, and work correctly on the resulting >> >> system. >> >> (1) The reason for this, to put it a bit simplistically, is that we >> don't require apt to perform the upgrade between stable releases in any >> particular order, right? Or are there other reasons distinct from this >> one that I'm missing? I think it would be good to state the thing about >> apt (in better language than mine) in the text. > > I think that's the main reason. We have not traditionally mandated > the use of a special upgrade tool like Ubuntu's do-release-upgrade(8), > so the upgrade happens in whatever order apt chooses, which can vary > between machines. > > Another reason why I think we want Debian 12 packages to be installable > onto non-merged-/usr systems is that to be able to do our development work, > they need to be installable onto testing/unstable systems, which (again) > means that the upgrade order is undefined. Right, we're on the same page then, but would you agree with me that the resolution should state this justification explicitly? > We also have best-effort support for partial upgrades, either > oldstable -> stable or stable -> testing/unstable: upgrading only a > subset of the available packages, plus their mandatory dependencies, > but without also upgrading apparently-unrelated packages. This can > only ever be partially supported, because it leads to a combinatorial > explosion of possible partially-upgraded systems, and realistically we > can never test them all; but I think it's best if we try to avoid > knowingly making this worse. I'd suggest we don't mention this as it's much more obscure and the above is sufficient justification. >> (2) Some people on -devel would seem to think that we can have smooth >> upgrades from bullseye to bookworm without requiring support for >> non-merged-/usr in every single package in bookworm, i.e., without >> supporting non-merged-/usr for testing/unstable installations during the >> current release cycle. > > Some people on -devel have argued that it would be OK to require use of > a special upgrade tool analogous to Ubuntu's do-release-upgrade just this > once, or that it would be OK to require a particular upgrade sequence. For > example, we could ask users to install the usrmerge package first, and > then upgrade; or if dpkg is modified to special-case the merged-/usr > aliasing symlinks, then we might ask users to upgrade dpkg first, and > then upgrade the rest of the system. > > I think there is considerable anecdotal evidence that many Debian users > do not read the release notes, and if we ask them to carry out an upgrade > procedure more complicated than > > $editor /etc/apt/sources.list && apt update && apt full-upgrade > > they will often ignore that request and still expect their upgrade to > work (because in practice it often does, and we've been training users > to expect that for years). That makes me reluctant to require a special > upgrade procedure if it is not strictly necessary. This is persuasive. What do you think about including it in the text? Specifically, mentioning that we are deciding, for the project, that we are not going to do this using something like do-release-upgrade(8). >> What smcv has been arguing for is the most conservative option. But >> which of the following is it the TC wants to say: >> >> - we are sure that this is the only way to ensure smooth upgrades, such >> that it pretty much follows from our previous decision on merged-/usr >> >> - we think there might be viable alternatives to requiring every package >> in bookworm to work on both layouts, but we aren't sure they are safe >> enough, so we're recommending a simple and conservative approach >> >> - we think that ensuring non-merged-/usr testing/unstable installations >> work during this release cycle is reason enough to take this highly >> conservative approach > > I'm honestly not sure which of these is "the" reason why I'm recommending > the conservative approach. Some combination of your second and third > points, I suppose? Based on what you say above I think it's the second and third, indeed. If we add to the text the things I'm suggesting we add, I think this sort of query about our motivations will not arise in the minds of readers. Thanks! -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature