Hello, I have no personal stake either, the same as the others who already replied, but I guess I'll chime in as well.
On Mon, Jun 14, 2021 at 02:39:30PM +0200, Helmut Grohne wrote:
> > I think using triggers has an obvious benefit here, but depending in the
> > intended semantics of `/etc/shells`, implementing the part about preserving
> > user changes may be difficult. A possible solution could be moving
> > `/etc/shells` to `/var` and replacing it with a symbolic link when its
> > contents
> > match with the generated one one.
>
> At this time, my personal preference would be turning /etc/shells into a
> symbolic link to an autogenerated file. Replacing that link with a
> manually maintained file would keep the original flexibility at the
> slightly increased cost of having to manually update it for added or
> removed shells while providing significant improvements for the vast
> majority of users.
I have an enhancement proposal to your suggestion.
Add an /etc/shells.add and /etc/shell.remove or somesuch, that are
parsed while generating the proposed /var/<something> file, that are to
be used by the system administrator to instruct the debianutils trigger
to either remove a shell from the list even if it's installed, or to add
a shell to the list even if it's not installed. It probably means that
the code handling the /var/<something> file should probably be callable
by other means than just a dpkg trigger, so that the system
administrator can force update the shell list when they update
add/remove files.
This way you'd entirely remove another case where you'd need to remove
the symlink and as such lose the ability to auto-update the file when
you add/remove shells (that are not otherwise already listed in the .add
and .remove files), and, in fact, make it possible for those systems to
be even more declarative since the administrators wouldn't be messing
with files that are already managed by other tools.
(this is somewhat inspired by /etc/hosts.{allow,deny})
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
