On Fri, Sep 15, 2023 at 03:17:42PM -0600, Sam Hartman wrote: > Luca> And we can have a > Luca> working, bootable Debian container with only /usr. > I'm not actually convinced this is a good thing. > (I don't think it's a bad thing--I just am not convinced it's something > we should be working toward). > I'd rather see project level discussion of this and a decision that is > something we want. > I have significant discomfort aligning what you say (pam is the last > blocker) with what several people said earlier in the week. > What I heard is that there was no project consensus to do this, and that > people were running experiments to see what is possible. > If I make a change in pam and we're suddenly at a place where there are > no blockers and we're moving forward, I think people in the project > would understandably feel disenfranchised. > To bystanders, "we're running experiments to see what's possible," means > a decision is far off. I agree with you that these sorts of changes should be discussed openly in debian-devel, and plans talked about, before we get too far down the path. Just as I advocated for when it came to DPKG_ROOT support in base packages. I do not want to see the fact that maintainers of base packages have individually decided it's worthwhile to support a thing, to be used to strong-arm other maintainers into feeling they also have to support a thing for which there may be no consensus. However, I do not think that *reaching* a consensus about this being a good thing needs to be a blocker for maintainers deciding to support it. As pointed out, there is nothing in Policy requiring any package to ship any files in /etc, it's only required that if a user wants to change the defaults for a package they should be able to do so via /etc (or /var). If it happens that all maintainers of base packages believe they can satisfactorily meet the needs of their users to configure those packages without shipping any default configs in /etc, those maintainers are free to make such changes to support this, without waiting for project consensus. Doing so doesn't penalize existing users and use cases of Debian (unless the maintainer is wrong about meeting users' needs, or makes a hash of the upgrade handling). And it would allow Debian to be used in contexts where it can't be today. It's basically a win-win. > I feel like if I were to fall in on this, I might be helping cause > something to happen at a technical level, bypassing discussion that I > believe would be healthy for the project. > I appreciate the value of doing work and having people who are willing > to do the work have a larger share of power in the decision making. I would like to see that discussion happen. I don't think this thread is that discussion, and I'm not stepping forward to drive it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature