Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636
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 signature.asc Description: PGP signature
Bug#994275: Reverting breaking changes in debianutils
On Sat, Sep 25, 2021 at 11:31:41AM +0100, Simon McVittie wrote: > This seems a good opportunity to ask what I think is a key question here: > what do you consider debianutils' mission to be? The package description uses the phrases "specific to Debian" and "installation scripts of Debian packages". The fact that debianutils is used on non-deb operating systems suggests a failure at the former. The fact that 95% of my inbox consists of hatemail about the interactive usage of `which` suggests a failure at the latter. debianutils should consist solely of utilities that are actually deserving of Essential status, that are maintained by debianutils upstream, and do not needlessly duplicate functionality provided by other sources. Divestiture of mktemp, readlink, sensible-editor, sensible-pager, sensible-browser, tempfile, and possibly mkboot were adjustments toward a better debianutils. mktemp and readlink have been replaced by superior versions. sensible-* live in a non-Essential package in which presumably someone cares about them. tempfile and mkboot are no longer around to confuse people. Did people see these things as progress when they happened? I would imagine that the people who were verbally abusing me and flinging stop energy around at the time did not. Does anyone really miss the old debianutils mktemp now?
Re: Bug#995569: debhelper: act on service files placed in usr/lib/systemd/system
Control: blocked -1 by 994388 (@Tech-ctte in BCC: Consider this email as an FYI that this bug is waiting for your resolution of #994388. I do not expect follow up from you in any official capacity, but I would strongly appreciate if you would explicitly clarify how this request will fit into your advice for the transition plan once you have that.) Ferenc Wágner: > Package: debhelper > Version: 13.5.2 > Severity: normal > > Dear Maintainer, > > If some upstream install procedure places service files under > /usr/lib/systemd/system, dh_installsystemd won't notice those in > debian/tmp during package build, thus such units won't be enabled and > started on the installation of the resulting package. > > I think this could (and should) be done irrespective of the usrmerge > transition and whether maintainer-provided unit files are installed into > /usr/lib or /lib, because this has little chance to change anything > automatically (unless some packages have been shipping unit files under > /usr/lib with the very purpose of not activating and starting them). > Hi Ferenc, Thanks for your bug report and I appreciate why you want this feature. Unfortunately, I have no intention of acting on this request until the tech-ctte has resolved their advice on how they want the /usr-merge transition to be resolved (per #995569). Some might argue that this request is independent of the /usr-merge transition. However, adding support for this feature will enable maintainers to move files from / to /usr much easier than previously and a key point here is whether that would be seen as supporting/enabling maintainers in going against the (likely) advice of the tech-ctte to not do "per package/path" transitions. Obviously, a maintainer *can* do this manually without debhelper - but they would do so at their own peril. Whereas if I add this support someone will definitely leverage that feature to move from / to /usr even if that would contradict the recommendation from the tech-ctte. Sadly, it does leave you hanging if you have an upstream package that uses /usr/lib where you would manually have to move that to /lib or not use debhelper at all. And if you move it to /lib, you would eventually have to "undo" that at a later stage. I wish I could provide you with something better, but I am personally not ready to invest in implementing this feature while there is a considerably risk that I would need to revert it again or it would be interpreted as "promoting dissent" against the upcoming /usr-merge transition[1]. ~Niels PS: The tech-ctte have not officially clarified their resolution on the /usr-merged migration, but so far I have yet to see a draft / suggestion that include "migrate paths manually in packages before $FLAG_DAY" as a proposed solution. Instead the drafts point to quite the opposite. [1] I have raised objections in public about some of the /usr-merge transition plans. I feel this is not an entirely theoretical concern that other project members would see it as a statement from me if I was to implement this feature without the explicit approval of the tech-ctte at this point in time.
