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
