On Mar 18, Helmut Grohne <hel...@subdivi.de> wrote: > I think that it is quite obvious that /etc/shells is debianutils' > territory. When I found that on some systems /etc/shells was out of sync > with /var/lib/shells.state, I was quite puzzled until I noticed that > usrmerge messes with this file. This really is debianutils' It is expected that /etc/shells can be edited by system administrators, I have been doing that forever in my career as a professional system administrator and until now I was not even aware of these programs from debianutils. Hence my reasoning that having convert-etc-shells modify the file would not be harmful, and so far I am not aware of any practical problem that this has ever caused.
I also see that you wrote update-shells in 2021, but convert-etc-shells was added to usrmerge in 2016. > If and only if usrmerge is used, convert-etc-shells turns /bin/sh into > /usr/bin/sh. So whenever we start out merged and use usr-is-merged, > /usr/bin/sh goes missing. Right. But both update-shells and usr-is-merged are new to bookworm, and I remember that having the /usr/ paths in /etc/shells is not usually needed, so this explains why nobody has reported actual problems so far. > I think the best solution here would be merging convert-etc-shells into > update-shells. No objections if you can do the work, I will not miss it. > Whenever we run update-shells, it should check whether > the system is already merged and when it is, perform the equivalent to > convert-etc-shells. Then usrmerge can just install an empty (except for > a comment) /usr/share/debianutils/shells.d/usrmerge to trigger > update-shells and things become fully reproducible in all cases, because OK. (Also, would you mind moving /var/lib/shells.state to /var/lib/misc/?) -- ciao, Marco
signature.asc
Description: PGP signature
