Adding /usr/local/etc/rc.d to the base rcorder

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Adding /usr/local/etc/rc.d to the base rcorder

dougb
Howdy,

The idea to incorporate the scripts in the local startup directories
(currently defined as /usr/local/etc/rc.d /usr/X11R6/etc/rc.d, or
substitute whatever your PREFIX/LOCALBASE/X11BASE is), into the overall
rcorder that the scripts in /etc/rc.d follow has been around basically since
the new rc.d framework was introduced, but has been very difficult to
implement. A thread on the freebsd-rc list back in June discussed the
ramifications of this change, and how it might possibly be implemented
safely. Since then, I've put together a set of patches that implement one
approach to this change.

Now that 6.0-RELEASE is done, I'd like to move fairly quickly in
implementing this in HEAD, and once the bogons are shaken out, I'd like to
MFC it to RELENG_6 prior to 6.1-RELEASE.

I want to point out several things at the outset. This is _one_ possible
approach to this problem. One that I believe will work well, and minimizes
the pain of the transition. However, I am not necessarily tied into every
detail of my patch, or even the approach generally. However, we need to move
forward on this, and without compelling reasons to do things differently, I
am confident that this approach will work.

1. In order for this to work, we need to first get the disks mounted.
(Thanks to Brooks for this, and other important insights). Therefore I'm
proposing that we split the rcorder function into two parts, one "early"
stage that takes care of everything up to mountcritremote; then redo
rcorder, skipping the scripts that were done in the early stage, and
incorporating the scripts in /usr/local/etc/rc.d, etc. This is not a
"perfect" approach, as theoretically some cases where a local package might
want to insert itself into rcorder before mountcritremote, however given the
various tradeoffs we have to make (for example, diskless booting), this is
at least a reasonable place to start. Compare
http://people.freebsd.org/~dougb/rcorder.all and
http://people.freebsd.org/~dougb/rcorder.early to see how the ordering as it
exists in HEAD at the moment would be affected. Of 127 scripts, 52 would be
in the early stage. (/etc/rc.d/tmp is being forced into the early stage by
my patch in order to avoid non-deterministic behavior when local scripts are
added to rcorder. This could just as easily be forced into the late stage.)

My method for implementing the distinction between the early boot stage and
the later is derived from an idea suggested by J.R. Oldroyd. It stops
processing in the early stage once mountcritremote is done. The "late" stage
first finds scripts in the local directories, then runs rcorder again over
both lists. It starts processing after mountcritremote is reached.

2. The next aspect of this plan is how to manage the transition for the
ports. There are two phases to this. First, adding code to /etc/rc (and
rc.subr) to pick up those scripts in local_startup that are ready to be
added to rcorder. This is done by grep'ing for '^# PROVIDE:' in the script.
This method is not entirely foolproof, as for example the cups.sh startup
script is (from our perspective) an "old style" script, however it contains
the PROVIDE line for NetBSD's purposes. Thus, some care will have to be
taken during the transition period to avoid problems.

By my count, there are roughly 640 ports that install some sort of startup
script. Of these, roughly 345 have transitioned to the new style of rc.d
scripts (based on the presence of USE_RCORDER/USE_RC_SUBR in the Makefile).
Thus, there are roughly 300 ports with scripts that would _potentially_ have
problems. Of these, I'm confident that the vast majority would work without
modification, as the number of possibly fatal error conditions are very
small.

The situation with cups.sh above is the only one I've encountered, but there
may be others. There are two more potential problems with the new style
scripts that are already in the ports tree. First, there are probably some
scripts that have errors in them that will not be exposed until they are run
within the rcorder context. The other problems that are almost sure to arise
are scripts whose ordering needs to be adjusted (via REQUIRE/BEFORE, etc.).
These things will need to happen in order for the transition to be
successful in any case, so although it is sure to be a non-zero amount of
work, it's work that will have to be done regardless of what method is
chosen to incorporate the local_startup scripts into rcorder.

The other part of this transition is to modify the localpkg script. This is
done using some ideas and code from J.R. Oldroyd. Brooks, and myself. First
we sort out the scripts that start with a number (like 000.foo.sh) and run
them in numerical order, as a lot of work has gone into this style of
ordering already. Then we run the scripts that start with a letter. The
original idea here was to use rcorder in localpkg, however in my testing I
found that it's simpler to just run the new style scripts in the base
rcorder, and run everything else in localpkg. Therefore, the function that
searches for these scripts eliminates any that use the new rc.d style first.
These changes dramatically simplify the localpkg script.

3. The last part of this proposal is to apply the same changes to how we
pick up local scripts in rc to the shutdown process, both in rc.shutdown and
in localpkg.

My patch to implement all this is at
http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome.


Regards,

Doug

--

    This .signature sanitized for your protection

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Adding /usr/local/etc/rc.d to the base rcorder

Brooks Davis
On Tue, Nov 29, 2005 at 03:13:37AM -0800, Doug Barton wrote:
> My patch to implement all this is at
> http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome.

This looks pretty good to me.  Thanks for working on this.  A few
comments:

- I have this vague feeling that we should replace most dependencies on
  mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS.
  This isn't important. :)
- Is the exclusion of *.sample sufficient?  We obviously don't want to
  be too broad, but I'd be inclined to include .bak, .orig, and maybe
  .sav for now.
- I'm worried about including .sh scripts in the new list during the
  transition period.  It seems likely that is going to cause significant
  pain.
- When do we want to start complaining about old scripts?  One idea is
  to first ban them in ports and have Kris add a check for them on the
  ports cluster followed by enabling a warning in the startup scripts.
  Other policies are possible.

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding /usr/local/etc/rc.d to the base rcorder

dougb
Brooks Davis wrote:
> On Tue, Nov 29, 2005 at 03:13:37AM -0800, Doug Barton wrote:
>
>>My patch to implement all this is at
>>http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome.
>
>
> This looks pretty good to me.  Thanks for working on this.

No problem. I had a feeling you'd like the fact that I dropped all that
keyword stuff. :)

> A few comments:
>
> - I have this vague feeling that we should replace most dependencies on
>   mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS.
>   This isn't important. :)

Right, this can be revisited later if needed. The more I thought about this
the more I liked the concept of what JR suggested, although obviously I
implemented it in a slightly different manner. I'm hesitant to add more
pseudo-targets, as I think using mountcritremote is a good "clear bright
line" for this purpose. I also have a fantasy down the road (not sure how to
implement it yet) of making the point to split early/late configurable. For
example, I can imagine a scenario where someone might want to put the split
at mountcritlocal. However, this is a good safe place to start.

> - Is the exclusion of *.sample sufficient?  We obviously don't want to
>   be too broad, but I'd be inclined to include .bak, .orig, and maybe
>   .sav for now.

Heh, that's the opposite of what you said last time. :)  I actually decided
to take your advice and take all the pain up front. I think if we start with
this in HEAD, and give people sufficient warning, we can handle the problem
cases pretty easily. And of course, if I'm wrong, this is also easily fixed.

> - I'm worried about including .sh scripts in the new list during the
>   transition period.  It seems likely that is going to cause significant
>   pain.

Once again, I hope not, but this is the area where I have the most concern.
My post was pretty long already, so I cut the section where I discussed the
relative virtues of foo vs. foo.sh, but one thing I do plan to offer port
authors is help with installing their scripts as foo instead of foo.sh if
OSVERSION is > N, where we can slide N down through 610000 at least. At some
point (years down the road obviously) when we've dropped support for
RELENG_5 in ports, this can all be removed.

I'm still ambivalent about whether to backport this into RELENG_5 btw. On
the one hand it wouldn't be too hard to do, but on the other hand I'd like
to do everything I can to convince people of the value of moving to RELENG_6
asap. Thoughts on this topic are welcome.

> - When do we want to start complaining about old scripts?  One idea is
>   to first ban them in ports and have Kris add a check for them on the
>   ports cluster followed by enabling a warning in the startup scripts.

My feeling is that we probably want to deprecate them in 7-Stable, and stop
supporting them in 8-Stable, but I'm open to suggestions here too.


Doug

--

    This .signature sanitized for your protection

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Adding /usr/local/etc/rc.d to the base rcorder

Yar Tikhiy-2
On Wed, Nov 30, 2005 at 05:20:11PM -0800, Doug Barton wrote:
> > On Tue, Nov 29, 2005 at 03:13:37AM -0800, Doug Barton wrote:
> >
> >>My patch to implement all this is at
> >>http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome.
> >
> >
> > This looks pretty good to me.  Thanks for working on this.

Please accept my appreciation of your efforts, too!

> > A few comments:
> >
> > - I have this vague feeling that we should replace most dependencies on
> >   mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS.
> >   This isn't important. :)
>
> Right, this can be revisited later if needed. The more I thought about this
> the more I liked the concept of what JR suggested, although obviously I
> implemented it in a slightly different manner. I'm hesitant to add more
> pseudo-targets, as I think using mountcritremote is a good "clear bright
> line" for this purpose. I also have a fantasy down the road (not sure how to
> implement it yet) of making the point to split early/late configurable. For
> example, I can imagine a scenario where someone might want to put the split
> at mountcritlocal. However, this is a good safe place to start.

With a pseudo-target for filesystems, will we still need the split
hardcoded in /etc/rc?  Using a single run of rcorder should be
sufficient if all our rc.d scripts specify correct interdependencies
between each other.  Using the pseudo-target would be a natural way
of doing so while keeping the possibility to move the split up and
down the boot sequence.

--
Yar
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Adding /usr/local/etc/rc.d to the base rcorder

Brooks Davis
On Fri, Dec 02, 2005 at 11:06:05AM +0300, Yar Tikhiy wrote:

> On Wed, Nov 30, 2005 at 05:20:11PM -0800, Doug Barton wrote:
> > > On Tue, Nov 29, 2005 at 03:13:37AM -0800, Doug Barton wrote:
> > >
> > >>My patch to implement all this is at
> > >>http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome.
> > >
> > >
> > > This looks pretty good to me.  Thanks for working on this.
>
> Please accept my appreciation of your efforts, too!
>
> > > A few comments:
> > >
> > > - I have this vague feeling that we should replace most dependencies on
> > >   mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS.
> > >   This isn't important. :)
> >
> > Right, this can be revisited later if needed. The more I thought about this
> > the more I liked the concept of what JR suggested, although obviously I
> > implemented it in a slightly different manner. I'm hesitant to add more
> > pseudo-targets, as I think using mountcritremote is a good "clear bright
> > line" for this purpose. I also have a fantasy down the road (not sure how to
> > implement it yet) of making the point to split early/late configurable. For
> > example, I can imagine a scenario where someone might want to put the split
> > at mountcritlocal. However, this is a good safe place to start.
>
> With a pseudo-target for filesystems, will we still need the split
> hardcoded in /etc/rc?  Using a single run of rcorder should be
> sufficient if all our rc.d scripts specify correct interdependencies
> between each other.  Using the pseudo-target would be a natural way
> of doing so while keeping the possibility to move the split up and
> down the boot sequence.
You have to run rccorder twice because until mountcritremote (or an
equivalent pseudo target) you aren't garenteed to have access to all the
files rcorder needs to parse.

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding /usr/local/etc/rc.d to the base rcorder

Brooks Davis
In reply to this post by dougb
On Wed, Nov 30, 2005 at 05:20:11PM -0800, Doug Barton wrote:

> Brooks Davis wrote:
> > On Tue, Nov 29, 2005 at 03:13:37AM -0800, Doug Barton wrote:
> >
> >>My patch to implement all this is at
> >>http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome.
> >
> >
> > This looks pretty good to me.  Thanks for working on this.
>
> No problem. I had a feeling you'd like the fact that I dropped all that
> keyword stuff. :)
>
> > A few comments:
> >
> > - I have this vague feeling that we should replace most dependencies on
> >   mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS.
> >   This isn't important. :)
>
> Right, this can be revisited later if needed. The more I thought about this
> the more I liked the concept of what JR suggested, although obviously I
> implemented it in a slightly different manner. I'm hesitant to add more
> pseudo-targets, as I think using mountcritremote is a good "clear bright
> line" for this purpose. I also have a fantasy down the road (not sure how to
> implement it yet) of making the point to split early/late configurable. For
> example, I can imagine a scenario where someone might want to put the split
> at mountcritlocal. However, this is a good safe place to start.
Ah, that makes sense.  I do have to say that the names for the mount
bit are misleading. mountcritlocal mounts everything local, not just
important things and mountcritremote does the same.  I like the idea of
being able to start at mountcritlocal.  That will actually be possible
on almost all systems including all the diskless systems I build.

> > - Is the exclusion of *.sample sufficient?  We obviously don't want to
> >   be too broad, but I'd be inclined to include .bak, .orig, and maybe
> >   .sav for now.
>
> Heh, that's the opposite of what you said last time. :)  I actually decided
> to take your advice and take all the pain up front. I think if we start with
> this in HEAD, and give people sufficient warning, we can handle the problem
> cases pretty easily. And of course, if I'm wrong, this is also easily fixed.
>
> > - I'm worried about including .sh scripts in the new list during the
> >   transition period.  It seems likely that is going to cause significant
> >   pain.
>
> Once again, I hope not, but this is the area where I have the most concern.
> My post was pretty long already, so I cut the section where I discussed the
> relative virtues of foo vs. foo.sh, but one thing I do plan to offer port
> authors is help with installing their scripts as foo instead of foo.sh if
> OSVERSION is > N, where we can slide N down through 610000 at least. At some
> point (years down the road obviously) when we've dropped support for
> RELENG_5 in ports, this can all be removed.
My concern isn't switching port over, that's a fairly easy task.
Instead, it's dealing with the transition period where every halfbaked
already installed script in /usr/local/etc/rc.d has the opportunity to
royally screw up the entire boot process by stomping on global variable
since it's run as a .sh script.  My concern is that we may end up having
to require a "portupgrade -af" and that's going to be unacceptable on
6-STABLE.

> I'm still ambivalent about whether to backport this into RELENG_5 btw. On
> the one hand it wouldn't be too hard to do, but on the other hand I'd like
> to do everything I can to convince people of the value of moving to RELENG_6
> asap. Thoughts on this topic are welcome.

I agree that it's worth not doing the MFC just to push people toward
RELENG_6.  

> > - When do we want to start complaining about old scripts?  One idea is
> >   to first ban them in ports and have Kris add a check for them on the
> >   ports cluster followed by enabling a warning in the startup scripts.
>
> My feeling is that we probably want to deprecate them in 7-Stable, and stop
> supporting them in 8-Stable, but I'm open to suggestions here too.

That sounds reasonable.  My thought would be to MFC to 6 and then start
griping about old style scripts in HEAD pretty much immediately.

The real issue in my mind is actually not so much the transition in the
base system as the transition in ports.  That's really a policy question
for portmgr.  I'd personally like to see an immediate ban on non rc.subr
scripts enforced by a test on the ports cluster and a round of marking
problem ports BROKEN.  That would probably fix things in a matter of
weeks.  After all, rc.subr scripts are easy to write and if there's a
hugely complicated script that the maintainer doesn't want to convert,
they can always install in over in libexec and wrap it with a simple
rc.subr script.

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

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Adding /usr/local/etc/rc.d to the base rcorder

dougb
Brooks Davis wrote:

> On Wed, Nov 30, 2005 at 05:20:11PM -0800, Doug Barton wrote:
>> Brooks Davis wrote:
>>> On Tue, Nov 29, 2005 at 03:13:37AM -0800, Doug Barton wrote:
>>>
>>>> My patch to implement all this is at
>>>> http://people.freebsd.org/~dougb/local-rcorder.diff. Comments are welcome.
>>>
>>> This looks pretty good to me.  Thanks for working on this.
>> No problem. I had a feeling you'd like the fact that I dropped all that
>> keyword stuff. :)
>>
>>> A few comments:
>>>
>>> - I have this vague feeling that we should replace most dependencies on
>>>   mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS.
>>>   This isn't important. :)
>> Right, this can be revisited later if needed. The more I thought about this
>> the more I liked the concept of what JR suggested, although obviously I
>> implemented it in a slightly different manner. I'm hesitant to add more
>> pseudo-targets, as I think using mountcritremote is a good "clear bright
>> line" for this purpose. I also have a fantasy down the road (not sure how to
>> implement it yet) of making the point to split early/late configurable. For
>> example, I can imagine a scenario where someone might want to put the split
>> at mountcritlocal. However, this is a good safe place to start.
>
> Ah, that makes sense.  I do have to say that the names for the mount
> bit are misleading. mountcritlocal mounts everything local, not just
> important things and mountcritremote does the same.  I like the idea of
> being able to start at mountcritlocal.  That will actually be possible
> on almost all systems including all the diskless systems I build.

I considered making mountcritlocal the starting point initially, however
when looking at what gets started between it and mountcritremote, I decided
that there weren't going to be a whole lot of ports that would want to
insert themselves in between. As with all things, this can be revisited down
the road if necessary.

>>> - Is the exclusion of *.sample sufficient?  We obviously don't want to
>>>   be too broad, but I'd be inclined to include .bak, .orig, and maybe
>>>   .sav for now.
>> Heh, that's the opposite of what you said last time. :)  I actually decided
>> to take your advice and take all the pain up front. I think if we start with
>> this in HEAD, and give people sufficient warning, we can handle the problem
>> cases pretty easily. And of course, if I'm wrong, this is also easily fixed.

I should also point out the rc.subr also excludes '*[~#]|*.OLD|*.orig|*,v',
so I figured anything that was left was worth carping about.

>>> - I'm worried about including .sh scripts in the new list during the
>>>   transition period.  It seems likely that is going to cause significant
>>>   pain.
>> Once again, I hope not, but this is the area where I have the most concern.
>> My post was pretty long already, so I cut the section where I discussed the
>> relative virtues of foo vs. foo.sh, but one thing I do plan to offer port
>> authors is help with installing their scripts as foo instead of foo.sh if
>> OSVERSION is > N, where we can slide N down through 610000 at least. At some
>> point (years down the road obviously) when we've dropped support for
>> RELENG_5 in ports, this can all be removed.
>
> My concern isn't switching port over, that's a fairly easy task.
> Instead, it's dealing with the transition period where every halfbaked
> already installed script in /usr/local/etc/rc.d has the opportunity to
> royally screw up the entire boot process by stomping on global variable
> since it's run as a .sh script.

Yep, that's a big concern, but it's pain that is inevitable if we're ever
going to make this transition.

> My concern is that we may end up having
> to require a "portupgrade -af" and that's going to be unacceptable on
> 6-STABLE.

Well, keep in mind that there are only about 650 ports that install startup
scripts (by my count). If we get the ones that need fixing done, and
versions rolled forward sooner rather than later, the RELENG_6 folks
shouldn't feel too much of the pain, it will mostly have been worked out in
HEAD.

> The real issue in my mind is actually not so much the transition in the
> base system as the transition in ports.  That's really a policy question
> for portmgr.  I'd personally like to see an immediate ban on non rc.subr
> scripts enforced by a test on the ports cluster and a round of marking
> problem ports BROKEN.  That would probably fix things in a matter of
> weeks.  After all, rc.subr scripts are easy to write and if there's a
> hugely complicated script that the maintainer doesn't want to convert,
> they can always install in over in libexec and wrap it with a simple
> rc.subr script.

Feel free to bring that suggestion up on the -ports list. :) I am hesitant
to go that route simply because I don't like telling other developers, "Here
is a whole big bunch o' work for you, have a nice day." I'm actually
interested to see what will happen with the existing scripts that are named
*.sh. I have 8 *.sh scripts in /usr/local/etc.rc.d, and only 1 failed.
Assuming that this 12.5% failure rate is representative (and there is no
evidence that it is), that's only 81.25 ports that need fixing, which leads
me to believe that the transition can be gradual rather than abrupt, but at
this point I think we'll just have to wait and see.

Doug

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Adding /usr/local/etc/rc.d to the base rcorder

Yar Tikhiy-2
In reply to this post by Brooks Davis
On Fri, Dec 02, 2005 at 08:35:39AM -0800, Brooks Davis wrote:

> >
> > > > A few comments:
> > > >
> > > > - I have this vague feeling that we should replace most dependencies on
> > > >   mountcritremote with a new pseudo target like FILESYSTEMS or MOUNTS.
> > > >   This isn't important. :)
> > >
> > > Right, this can be revisited later if needed. The more I thought about this
> > > the more I liked the concept of what JR suggested, although obviously I
> > > implemented it in a slightly different manner. I'm hesitant to add more
> > > pseudo-targets, as I think using mountcritremote is a good "clear bright
> > > line" for this purpose. I also have a fantasy down the road (not sure how to
> > > implement it yet) of making the point to split early/late configurable. For
> > > example, I can imagine a scenario where someone might want to put the split
> > > at mountcritlocal. However, this is a good safe place to start.
> >
> > With a pseudo-target for filesystems, will we still need the split
> > hardcoded in /etc/rc?  Using a single run of rcorder should be
> > sufficient if all our rc.d scripts specify correct interdependencies
> > between each other.  Using the pseudo-target would be a natural way
> > of doing so while keeping the possibility to move the split up and
> > down the boot sequence.
>
> You have to run rccorder twice because until mountcritremote (or an
> equivalent pseudo target) you aren't garenteed to have access to all the
> files rcorder needs to parse.

Now I see.  I obviously missed this point.  Thanks for clarifying it.

However, are there plans to allow for ports inserting theirselves
in the early stage?  E.g., a 3rd-party routing daemon can be needed
to fully start the network prior to doing mountcritremote.  And if
the routing daemon were built against older libraries in addition,
it would need the compat libraries in /usr/local/lib/compat added
to the ldconfig search path in advance.  This is the case I myself
ran into once.  Making the split between the stages movable to
mountcritlocal, as you proposed, would be a solution.  This can be
generalized to an rc.conf variable indicating the name of the rc.d
script to put the split after.

--
Yar
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

RE: Adding /usr/local/etc/rc.d to the base rcorder

Andrey V. Semyonov
In reply to this post by dougb
I apologise for wrong PR-group that a PR was sended to, but it seems to
be very strange that no attantion was made to it at all. And, I continue
to suppose that the PR's way to `rcorder` scripts via localpkg is more
simple (and works fine as I tested) that offered by Doug Barton.

http://www.freebsd.org/cgi/query-pr.cgi?pr=85206
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Adding /usr/local/etc/rc.d to the base rcorder

Yar Tikhiy-2
On Mon, Dec 05, 2005 at 10:35:27AM +0300, Andrey V. Semyonov wrote:
> I apologise for wrong PR-group that a PR was sended to, but it seems to
> be very strange that no attantion was made to it at all. And, I continue
> to suppose that the PR's way to `rcorder` scripts via localpkg is more
> simple (and works fine as I tested) that offered by Doug Barton.
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=85206

I'm afraid that your approach is considerably less general than
Doug's.  The problem with your approach is that /usr/local/etc/rc.d
scripts can be rcorder'ed only relative to each other and no script
from /usr/local/etc/rc.d can be inserted into the main /etc/rc.d
sequence at an arbitrary position.  With Doug's approach, the latter
is possible with the obvious limitation of /usr/local mounted already.

I think that the problem you reported has been solved in CURRENT and
the PR state may be changed at least to "patched."

--
Yar
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Adding /usr/local/etc/rc.d to the base rcorder

dougb
In reply to this post by Andrey V. Semyonov
Andrey V. Semyonov wrote:
> I apologise for wrong PR-group that a PR was sended to, but it seems to
> be very strange that no attantion was made to it at all. And, I continue
> to suppose that the PR's way to `rcorder` scripts via localpkg is more
> simple (and works fine as I tested) that offered by Doug Barton.

Thanks for bringing this PR to my attention, I just closed it in order to
help keep the PR database neat and clean. :)

Seriously though, the clamor for a more general approach (that allows local
scripts to be included in the overall rcorder) has been loud and long, and
there is no reason we can't overcome the barriers to make it happen.

Doug

--

     This .signature sanitized for your protection

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"