[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Do not plan to support /usr/lib/pam.d for Debian pam

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

Reply to: