Use of rcorder for local rc.d/*.sh scripts

[Brooks Davis]

Summary: after a fair bit of waffling, I've decided the issue of
transition complexity argues for only modifying localpkg at this time.

On Fri, Jun 17, 2005 at 09:38:31AM -0400, J.R. Oldroyd wrote:
> On Jun 15, 10:30, Brooks Davis wrote:
> > On Wed, Jun 15, 2005 at 12:29:48PM -0400, J.R. Oldroyd wrote:
> > > > 
> > > I meant first in localpkg.  Or in a localpkg-early script, but I don't
> > > see the need for an extra script.
> > 
> > The reason I think we may need an early script is that we're going to be
> > moving some scripts well before localpkg.
> > 
> OK, I see now localpkg isn't run 'till later than I realized.  So
> a new localpkg-early would run just after mountcritremote/MOUNTDONE?
> Would it just run the [0-9]*.sh files or would it also handle files
> tagged with "bootearly" as Doug proposed?

I would like to see it only handle [0-9]*.sh.  I would strongly prefer a
solution with no tags.

> > I think *.* is fine.  I'd prefer to complain about them from the
> > beginning so we catch any exceptions (possibly suppressing warnings for
> > obvious examples like *.bak, *.orig, *.sample).
> > 
> OK on the pattern, but don't we specifically want warnings for those
> files - they're precisely the ones we want folk to move.

I think my thought there was that we'd warn that we were skipping files
we might actually want to run.  (I'm not sure though since you've
trimmed so much context).  Warning on all of them is fine.

> > > If we're not changing /etc/rc and adding the transition functionality
> > > in localpkg, the transition localpkg will have to:
> > > 
> > > ...
> > >
> > I'd rather not support sourcing at all until full transition.  I'd
> > rather force porters to install files in /etc/rc.d for now if they want
> > sourcing.
> > 
> > ...
> >
> > Ah, I see why the disconnect on localpkg-early above.  I was thinking
> > we'd do the rcordering in /etc/rc in B which would change things a bit,
> > but could still be basically compatible.
> 
> Hmm.  I thought that for the transitional version, we'd agreed to NOT
> change /etc/rc or rc.subr so everything would be done in localpkg with
> a possible localpkg-early.

If we don't change rc, there's no point in localpkg-early.  I'm of two
minds about changing /etc/rc.  If we don't change it things are simpler,
but we get only part of the benefits of rcordering.  We would get the
benefits I'd personally use most (the ability of ports to depend on each
other), but some people seem to want to start things in other places.

> If you're now thinking we are OK to change /etc/rc and rc.subr even
> for the transitional version, I'm not clear why we'd keep localpkg
> at all and I don't see why we don't offer sourcing right away either,
> as long as we can clearly tell which files want it (which a new keyword
> would be a good indicator of).

I'd like to run non-rc.d scripts where they used to be run, rather than
pushing them all the way to the end.  That may not matter much, though
I certainly want them to run before bgfsck kicks off incase they take
longer than background_fsck_delay to start.  I feel sourcing is of
extreamly limited usefulness so I'd rather put it off than deal with
adding and processing tags to handle it.

> > I'm more concerned about supporting installing .sh scripts on 5.x for
> > the next two years than I am about supporting the installation of .sh
> > scripts to be sourced two years now.
> > 
> Based on your comment below, presumably this change won't need to go
> into the 5.x branch at all.  I'm now reading what you're saying as meaning
> we should put the transitional scripts into head and into the 6-RELEASE
> branch, and put the final one into 7.0.

Yes, that's how things work.

> > If we can't make major changes to the startup script processing in the
> > 6.x line once 6.0-RELEASE happens.  Anything that would break user
> > scripts would be specifically disallowed.  The rule of the project is
> > that we generally have to deprecate a major interface for one release
> > branch before we can break it.  The rules for determining which scripts
> > are run definitely falls into this category.  Remember, we're not just
> > dealing with ports, we're also dealing with weird user scripts so we
> > need to give them plenty of warning.  If we weren't so close to 6.0
> > release, we might be able to get away with warnings in 5.x and full
> > deprecation in 6.0, but I think we're too late for that.  This is why
> > I'd like to see some modifications to /etc/rc in addition to localpkg.
> > 
> So be it then.  Seems like a long transition to me, but if those are
> the rules, no problem.

Those the rules because we get enough screaming if we make incompatable
changes between releases with plenty of notice and documentation.  It's
annoying sometimes, but especialy when dealing with ports, we're stuck
with it.

> So what's needed next?  Do you want more patch suggestions from me?
> If so, I still need to clear up whether it's rc/rc.subr that'll
> change or localpkg/localpkg-early or all of these.  Or, do you and
> Doug have enough to take it from here?

I think we're agreed that our end goal is that in 7.0 all scripts in
$local_startup will be sorted into the full set of scripts after
mountcritremote.  Now we need to nail down our feature set for 6.0 and
get it implemented.  I'm going to be gone all next week so I won't be
able to help much with that unfortunatly.  When I get back, network
interface startup issues will be my priority so I'd prefer it if you
could work on patches.

The problem I've been having with decided if we should confine changes to
localpkg is that I don't have enough information about what users want
from rcordering.  I'd like to be able to specify ordering between ports
or between daemons in the same port.  If that's what most other people
need, we should just modify localpkg and put /etc/rc modifications off
until later.  I'm not sure how useful full ordering is in practice.

One major advantage of purly localpkg just occured to me which is that
if we do that, we can avoid all the special casing in /etc/rc because
we'll only make changes there when we do the full transtion.  I think
that's sufficently compelling to vote for localpkg.  Port maintainers
who want full rcordering can still use RC_ORDER to install their scripts
in /etc/rc.d so that's not a big limitation.

In that case I think we need two things before 6.0.  First, an updated
localpkg script.  Second, modifications to bsd.port.mk to support
installation of rc.d script with or without .sh extensions based on
OSVERSION (to be bumped when localpkg is updated).  My prefrence at the
moment is to just strip the .sh from the scripts listed in USE_RC_SUBR
and have people who want their scripts sourced use RC_ORDER to install
them in /etc/rc.d.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20050617/3f5e7c77/attachment.bin