[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 04:05:50PM -0700, Steve Langasek wrote:
> On Fri, Sep 15, 2023 at 09:53:24PM +0100, Luca Boccassi wrote:
> > With the provision that I know next to nothing about pam - if I
> > understood correctly how it works, why not simply do both? Ship the
> > default file in the package under both /usr and /etc. Then, you get
> > the semantics you want with local changes tracking, and /etc wins over
> > the defaults. And we can have a working, bootable Debian container
> > with only /usr. As far as I've been told, pam is the only blocker
> > there - for a minimal image of course, but that's still quite a good
> > achievement. Wouldn't this work, or am I missing something?
> While I have applications downstream which also care about empty /etc, the
> current situation is that this wouldn't help because almost all the
> PAM application configs in Debian reference one or more of
> common-{account,auth,password,session,session-noninteractive} which are
> constructed at package install time and therefore are inappropriate to ship
> in /usr.

I do not believe the files being constructed at install time makes them
inappropriate to ship in /usr, We have precedence for doing that, 
compiled bytecode for python is essentially the same case.

If you follow the argument for /usr to its logical conclusion of being
the complete image, you end up moving state of the image (as opposed to
the system) from /var/lib to /usr as well, for example /var/lib/dpkg and

To my knowledge, similar changes are already implemented in higher
paced distributions.

Potentially there should be a /usr/var to encapsulate image state
as opposed to image data but that's somewhat bikeshedding.

debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Attachment: signature.asc
Description: PGP signature

Reply to: