Re: RFC: Alternate patch to have true new-style rc.d scripts inports (without touching localpkg)

Mike Makonnen schrieb:

> So, I think the best course of action is to convert all ports startup
> scripts to rc.d format and either
> 	a) install them all automatically to /etc/rc.d
> 	b) leave it to the port maintainer to choose
> 	c) leave it to the user to choose.
> 
> If we go with b or c, then /etc/rc.d/localpkg will need to learn to order
> rc.d scripts. I have a patch for that which is similar to the one I committed
> except that it has a list of the broken scripts which end in .sh that it
> treats like old style scripts (this should preserve compatibility with those
> upgrading from an older release):
> http://people.freebsd.org/~mtm/patches/localpkg.diff

Having ports startup scripts available for topological sorting from the
start seems a good concept. I'd want to see all rcNG startup files put
into just one directory not choosen by the port writer but by the local
system administrator (with some sensible default). Non-converted port
startup scripts could still be executed from $PREFIX/etc/rc.d with "old"
semantics assumed.

But I guess we may want to impose two restrictions:

1) The startup files should be located below /etc/rc.d, but (IMHO)
    not _within_ /etc/rc.d. E.g. put ports' startup scripts into
    /etc/rc.d/ports/ (or /etc/rc.d/local/). That way, no port can
    accidently overwrite a _system_ startup script in /etc/rc.d.
    (Ports' startup files could still overwrite each other, but if
    their names were required to be derived from the port name, even
    that risk could be excluded.)

2) There could be one implicit dependency applied when sorting ports'
    startup scripts (the exact name being specified by the system rc
    files). That way, a restriction on the earliest time a port startup
    file is executed may be imposed, beyond the dependencies placed into
    a port's rc file itself. Else a badly written startup file may be
    executed way to early and "naive" users of a port may be mislead
    to assume a failure in the base system ...

Regards, STefan