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

[Jason Hellenthal]

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

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

> > If you still disagree after doing this then please by all means eradicate
> > rc.conf.d from rc.conf(5) and remove its functionality from rc.subr as it
> > is less than adequate for anybody other than a developers natural use.
> 
> I hope you'll understand if I politely decline your request.
> 

I was not expecting anything less than your typical response.

> > 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. This is not adding a new knob 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 ? can you sum that up for 
me please ? I would be quite interested in how you or anyone for that 
matter explain properly how this is actually working.


-- 

 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/34f6c7cd/attachment.pgp