Re: What are desired semantics for /etc/shells?

[Helmut Grohne <helmut@subdivi.de>]

On Thu, Jun 24, 2021 at 06:12:05PM +0200, Felix C. Stegerman wrote:
> It also means that on /usr-merged systems e.g. /bin/screen is not a
> "valid" shell, but /usr/bin/screen is (even though they are the same
> file), which may be fine in practice but seems counter-intuitive to
> me.

Valid concern. Do you think that I should include machinery specifically
for handling the /usr merge in update-shells? Automatically adding
/bin/screen on /usr-merged systems where shells.d contains
/usr/bin/screen is feasible. I see little value though as
/usr/bin/screen has always worked on Debian and why would anyone use
/bin/screen now?

> >  * While the order of /etc/shells will not be sorted, it will be
> >    deterministic if update-shells is run after all packages have been
> >    unpacked. Installing two packages one after another will still cause
> >    their order in /etc/shells to differ, but changing the order of
> >    /etc/shells could break comments left by administrators. So this is a
> >    compromise that partially improves reproducibility without regressing
> >    maintainability of /etc/shells. I hope that it is sufficient in
> >    practice.
> 
> Sorting /etc/shells if the only comment in it is the current
> |# /etc/shells: valid login shells
> on line 1 would seem acceptable to me.

That seems reasonable initially, but it makes the semantics much harder
to understand. You add a special case here.

I think that what I proposed slightly improves reproducibility. It may
not be the final solution, but it also does not make later sorting much
harder. If it turns out that /etc/shells is insufficiently reproducible,
we can fix update-shells and be done as it'll be run in postinst.

For this reasons, I'm in favour of deferring the reproducibility aspect.
I'm not making it any harder and possibly it actually becomes
sufficiently reproducible for practical applications.

> > for f in "$PKG_DIR/"*; do
> 
> Would it make sense to set LC_COLLATE for deterministic ordering here?

That's a good suggestion. I looked into this and things are complicated.
For one thing, whether to set LC_COLLATE depends on where /bin/sh points
to. When it happens to be dash, you run into #699177 and basically don't
care. In any case, setting LC_COLLATE does not hurt. When it happens to
be bash, LC_COLLATE doesn't have to be exported and is honoured
immediately. Therefore, we should set LC_COLLATE prior to globbing even
though the issue is mostly irrelevant (until #699177 is fixed). Thanks.

I also confirm the typo spotted by Étienne Mollier. Thank you as well.

Helmut