On Wed, Jun 12, 2019 at 13:45:24 -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Wed Jun 12 17:45:24 UTC 2019 > > Modified Files: > src/usr.sbin/postinstall: postinstall > > Log Message: > Remove hard-coded lists of rc files and generate them dynamically > from the sets. Fixes issues with automount, npf_boot etc. that were > never updated here!
Isn't it the job of etcupdate to install the new files? Also, from a quick look postinstall fix rc will happily overwrite any local modifications you made to rc.d scripts - yes, changing them is not the best practice, but life happens. Also isn't it kinda strange to install /etc/rc.d/shinynewd and not install /etc/shinynewd.conf? Deleting obsolete rc.d files in "rc" (not "obsolete") also looks kinda scary to me. Say, we obsolete oldd. Alice installs new base.tgz, the old /sbin/oldd is still there (she's careful not to run "fix obsolete") and she has it still enabled for now. Then "fix rc" will delete its rc.d script, won't it? Note that if you do etcupdate you will get new /var/db/obsolete/etc, so later when you are ready you can do "fix obsolete" and get the rc script deleted along with the obsoleted binary. I guess what I'm trying to say is, does it really make sense to try to make postinstall provide some of the etcupdate functionality but in an ad-hoc and not quite safe manner? We are effectively trying to support the scenario where you do NOT do a full update to the new etc.tgz and still expect things to run. This might be not an unreasonable scenario to support, but then we probably shouldn't install inconsistent subset of the new etc.tgz in a a potentially unsafe manner. I've been using etcupdate for ages so I only ever really used postinstall to fix "obsolete" and "catpages". etcupdate -a has some kinks and may be we should concentrate on fixing those instead? -uwe
