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

[J.R. Oldroyd]

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 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.


> > 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 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'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.
 
>
> 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.


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?

	-jr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 390 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20050617/fda58218/attachment.bin