unsolicited passwd file changes

[nevets]

It seems that OS upgrades force changes to my username entry in passwd file, forcing the TE to fish.
I prefer zsh.
Whilst I can retrospectively edit the line from fish back to zsh
'username':*1002:'username':/home/'useername':/usr/local/bin/zsh
Is there something in the upgrade process that can preserve my choice of TE?

[ericbsd]

It seems that OS upgrades force changes to my username entry in passwd file, forcing the TE to fish.
I prefer zsh.
Whilst I can retrospectively edit the line from fish back to zsh
'username':*1002:'username':/home/'useername':/usr/local/bin/zsh
Is there something in the upgrade process that can preserve my choice of TE?

An update should not change anything in passwd. Also, editing /etc/passwd is not best practice. It would be best to use pw or chsh to change the shell.

[nevets]

I think some pkg installs seem to effect changes in passwd. Last time I saw this was installing scanner related pkgs I think.
Perhaps there's an artefact somewhere in MATE configuration...?
chsh doesn't seem to update passwd to the new TE which is why I ee the file. Only then does MATE stop using fish.

[nevets]

If we seek to remove fish
pkg delete fish
then...
Installed packages to be REMOVED:
fish: 3.6.1_1
ghostbsd-utils: 22.10.11
So, why is ghostbsd-utils tied to the fish installation?
Is this what keeps editing and reverting my /etc/passwd file for user me?

[ericbsd]

Your shell should not be changed on update. There is nothing forcing fish back to a user.

[nevets]

Yet is has happened...
So,
1. Is it likely to crash my system if I remove root write access to the passwd file?
I'd like to trap the behaviour...
2. Is root able to reinstate write access later if I change the file permission?
I still think MATE might have an inclination to reassert fish if the associated pkgs are ungraded... somehow...

[ericbsd]

The best way to reproduce this would be to do pkg upgrade -f. If upgrades affect /etc/passwd it should be reproduced with that command.