RFC: Alternate patch to have true new-style rc.d scripts in
ports (without touching localpkg)
Oliver Eikemeier
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
problems:
- 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
> scripts
> 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
> came
> after PORTS the first time it will still be after ports after the second
> reordering.
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
rcorder(8).
> 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
Hmmm.... I believe this list is not complete, besides it looks like a
maintainance nightmare.
-Oliver
More information about the freebsd-current
mailing list