Hallo Helmut, Digression alert: some context around debootstrap in particular and d-i packages in general. Helmut Grohne <helmut@subdivi.de> (2023-08-16): > we've had quite some discussion about various aspects of finalizing the > /usr-merge in the past half year. […] > I hope we don't get anymore disagreement with this and would like to > proceed with merging and uploading the change. Simon intends to backport > this change and > https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/93 > to bookworm and bullseye via SPU. Getting that latter change into > bullseye is a prerequisite for converting buildd chroots to a merged > layout, which is a prerequisite for lifting the moratorium. In order to > avoid going through SPU multiple times, we'd like to do both changes at > once. > > More background is available in the DEP17 draft. I've put up a rendered > version at https://subdivi.de/~helmut/dep17.html. In there, P8 is the > item concerned with debootstrap and M19 is the mitigation I am proposing > in this bug. > > Is there any prerequisite you see missing before we can merge and upload > this change? Any aspect to be analyzed? Any situation to be tested? Any > conceptual aspect I am missing? > > In the absence of a response, I intend to move forward with a delayed > NMU in accordance with devref, but I strongly appreciate more eyeballs > as this change is not without risks. Ever since the --[no-]merged-usr options were introduced, and the default flipped a couple of times, I've deliberately stayed away from that topic. Especially since what to do really needed to be decided at the project level (that's not just a d-i topic). That was reinforced once bluca started implementing changes with a TC hat, and that explains the series of NMUs until now. I'm happy that people want to upload debootstrap; I have no strong feelings as to whether bluca or you should keep them as NMU. NMUs made sense to me initially, as it was making it clear to everyone that we have TC-decided-then-implemented changes. Since later contributions started including unrelated changes, those uploads really could have been team uploads, with or without uploaders adding themselves to the Uploaders field. The only thing I expect from people uploading d-i packages is being considerate in what they're changing, and not forgetting (when it comes to udebs) that most of our packages' end goal is getting used within the context of the installer; and to follow up if needed. (src:debian-installer is a little more special than other packages, but that's the general idea.) We've also been pretty liberal with adding people to the team so that they can push stuff in branches (master or otherwise); all that's needed in the end is someone taking responsibility for the actual upload to the archive. Later in the release cycle, we appreciate some coordination but my having a hand on the release hints and being able to ACK/NACK stuff in unstable for testing (while a temporary freeze is in place for udeb-producing packages) makes the upload coordination a nice-to-have yet non-essential topic. As you might have guessed, this digression wasn't for nothing: I don't consider myself knowledgeable enough about the merged-/usr situation, and I'm fine with trusting you folks. Problems have been brainstormed, plans have been elaborated, and you're willing to implement them. As long as you're happy with following up if needed, I'm happy to have you NMU debootstrap, team-upload it, or just upload it (adding yourself to Uploaders or not, at your discretion). Cheers, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature