RFC: Alternate patch to have true new-style rc.d scripts in
ports (without touching localpkg)
eikemeier at fillmore-labs.com
Mon Aug 16 16:08:26 PDT 2004
Mike Makonnen wrote:
> I have thought about this considerably, and I think the best solution
> is to have ports rc.d scripts installed to /etc/rc.d.
This is what I currently do with slapd, but this approach has multiple
- it violates the law that packages have to be PREFIX-clean, which has
some very unfortunate consequences from a packaging point of view.
- mergemaster barfs ever time (PR 64476)
- you can not be sure that the script is not started before the needed
filesystems are available.
> One of the problems
> with having them in a separate directory is that we don't know when
> that directory will be available, so we have to order the scripts
> in two phases: first /etc/rc.d and then the ports rc.d directory when
> it is ready. If we do this then there is the REAL possiblity that
> something may not get run the second time around. For example, let's
> say that /etc/rc re-orders all the scripts (base and local) when it
> hits the dummy script PORTS. Furthermore, after they are reordered we
> skip the scripts that come before PORTS. The problem is that When the
> are reordered if a particular script does not have a dependency on
> PORTS (or
> another script that requires PORTS) you are not guaranteed that if it
> after PORTS the first time it will still be after ports after the second
No, my patch simply start from the beginning, leaving out every script
that has already been executed. The worst thing that may happen is that
a script may be executed too late, which should be ok (call it a wrong
dependency in that case). So this is not a problem.
> While you can have workarounds and introduce hacks around this
> problem, I
> think the general messiness and potential problems of ordering scripts
> more than once makes it a bad solution.
As written above: already solved.
> Secondly, there is really no compelling reason that all ports be
> ordered with the base scripts. If a port is of such a nature that it
> needs to be started much earlier than it currently is, either the ports
> should install the script automatically to /etc/rc.d or it should give
> the user the option of choosing.
As stated above: you violate PREFIX with that, which makes it a bad hack.
> 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.
There is no compelling reason *not* to let ports script participate in
> If we go with b or c, then /etc/rc.d/localpkg will need to learn to
> rc.d scripts. I have a patch for that which is similar to the one I
> 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
> upgrading from an older release):
Hmmm.... I believe this list is not complete, besides it looks like a
More information about the freebsd-current