Re: CVS commit: src/usr.sbin/postinstall

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

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