Support for vendor locations (additional to /etc/shells)

[dvzrv]

Hi! I'm currently looking into the integration of /etc/shells in the packaging ecosystem on Arch Linux.
Our current way of dealing with /etc/shells is as follows:

• some shells (e.g. sh and bash) are in the file by default (probably for historical reasons)
• other shells sed themselves in and out of the file in package addition/ removal hooks

This means, that /etc/shells provides a form of state, which needs to be maintained by the package management system or the user, or by other means.
When looking at the concept of immutable systems with vendor locations such as /usr, it becomes non-trivial to deal with files such as /etc/shells which are really an accumulation of several inputs though.
Would it be possible to support a vendor location (e.g. /usr/etc/shells.d/ or /usr/lib/shells.d/), which is trumped by /etc/shells and may contain drop-in files?
That way providers of shell packages on distributions can just add their respective files containing the shell path(s) and executables such as chsh would (also) consume them from that vendor location.

The upside to this is, that a system can be run with a removed /etc and be bootstrapped from the vendor location and that this would simplify the packaging of shells on downstream distributions. I'm aware, that other projects would need to buy in on this as well (e.g. util-linux, pam)

[thkukuk]

Something like /usr/lib/shells.d and /etc/shells.d would be in line with what got discussed on the Linux image summit in Berlin in October and is the same approach as shadow supports already for /etc/login.defs. I'm pretty confident that we could also use libeconf for this, I will discuss this with our developers.

[jubalh]

Above mentioned PR is merged since a long time. This issue can be closed.