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 /var/lib/apt/extended_states. 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
signature.asc
Description: PGP signature
