[RFC][Change-Request] Create usefulness in rc.subr etc/rc.conf.d/*.conf namespace.

Tue May 10 05:35:39 UTC 2011

On Mon, May 09, 2011 at 09:55:10PM -0700, Doug Barton wrote:
> This will be my last post on this topic unless something new arises. 
> Please don't cc me on any more responses.
> 
> On 05/09/2011 21:08, Jason Hellenthal wrote:
> >
> > Doug,
> >
> > On Mon, May 09, 2011 at 07:40:18PM -0700, Doug Barton wrote:
> >> On 05/09/2011 16:57, Jason Hellenthal wrote:
> >>>
> >>> Doug,
> >>>
> >>> On Mon, May 09, 2011 at 04:27:54PM -0700, Doug Barton wrote:
> >>
> >>> Sorry Doug but rc.conf.d is already laid out for the user to use as
> >>> mentioned by rc.conf(5) with a suggested use but unfortunately has quite a
> >>> few side effects that I am not going to bother re-writing about again.
> >>
> >> I read what you have written to date, but I don't see anything other
> >> than "It doesn't work the way I want it to." I just re-read the
> >> description in rc.conf.5, and I think it's clear, but I wouldn't object
> >> to suggestions to improve it.
> >>
> >>> In reply to your previous email here is one exercise that should point
> >>> out the broken functionality fairly clearly or at least I hope clearly
> >>> enough that you realize how a normal user would look at it.
> >>>
> >>>   From scratch, no rc.conf.
> >>
> >> No normal user would do that, so I reject your premise. :)
> >>
> >
> > Ok let me re-state that because you seem to have taken that litterally as
> > absolutely no rc.conf. "A rc.conf but without the needed nfs related
> > parts" This is an example!.
> 
> Hence the smiley.
> 
> >>> Setup a NFS server with lockd, statd, mountd,
> >>> rpcbind using only rc.conf.d/${_name} namespace and then try starting
> >>> these services using service(8) and /etc/rc.d/* files. Then read
> >>> rc.conf(5) and tell me the suggestion for jail makes sense.
> >>
> >> The various nfs-related options are a particularly pathological case, no
> >> one is disputing that. However, for the vast majority of purposes the
> >> one-name-at-a-time method works fine. And given that most users don't
> >> need anything even approaching the type of functionality that you're
> >> proposing, I still don't see a problem.
> >>
> >
> > I was not asking your you opinion of the way it works. You asked for an
> > example and one was given and you seem to be all opposed to even going
> > through and testing out that example to see where the stumbling blocks are
> > as you apparently have no recognition of them now. NFS is not the only case.
> 
> To the extent I understand your paragraph above, I don't think you 
> really understand where I'm coming from at all. I don't need to follow 
> your suggestion, I already know that for the particular pathological 
> case you described the rc.conf.d method is not appropriate.
> 
> What you seem to be missing is that your suggestion is not necessary to 
> solve the problem. To the extent that it is necessary to provide a 
> solution to this at all, multiple solutions already exist.
> 
> >>> I do not quite understand why you take such an opposition against
> >>> something that fixes this broken functionality but yet retains its
> >>> original use.
> >>
> >> Gordon has already stated it fairly eloquently, but I'll paraphrase. Too
> >> much potential for user confusion, for too little benefit. I realize
> >> that to you this sounds like a simple change, but the problem is that
> >> when you add knobs, users twist them. So every change to something as
> >> fundamental as the boot system needs to have really strong justification.
> >>
> >
> > Sadly at this point you still seem to not realize the complicated state
> > that rc.conf.d is in.
> 
> I hope you'll understand if once again I respectfully disagree.
> 
> > This is not adding a new knob
> 
> I was using that in the colloquial sense. If you give users the chance 
> to do something, some percentage of them will do it.
> 
> > and you seem to miss
> > that part as well. This fixes that complication on the rc.conf.d directory
> > and it could be properly implemented in a way that it should have been in
> > the first place as the manual suggests.
> >
> >
> > What do you propose to do with the manual page ?
> 
> What I'm saying is that IMO there is nothing in rc.conf.5 that is 
> confusing, and if you believe that it needs to be clarified please feel 
> free to submit suggestions.
> 

Unfortuneately at Doug's request this will not be CC'd, but this is also 
the intention of this thread as well. As stated earlier in the thread with 
my proposal to tidy this up I also said that once it is laid out for 
something that is agreed upon that I would update the manual accordingly. 
Doing this before the said seen needed fixes to uncomplicate the use of 
rc.conf.d would be be a great loss of time as it would require documenting 
every rc.d script, the names that are exported from them and putting 
together every combination of such. This type of complexity is what is 
trying to be avoided while still allowing the user to create well named 
organized custom configurations.

-- 

 Regards, (jhell)
 Jason Hellenthal

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20110510/8c7033af/attachment.pgp