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

[Jason Hellenthal]

Gordon,

On Mon, May 09, 2011 at 04:50:57PM -0700, Gordon Tetlow wrote:
> On Mon, May 9, 2011 at 12:04 PM, Jason Hellenthal <jhell at dataix.net> wrote:
> >
> > Gordon,
> >
> > On Mon, May 09, 2011 at 10:32:18AM -0700, Gordon Tetlow wrote:
> >> On Mon, May 9, 2011 at 10:12 AM, Devin Teske <dteske at vicor.com> wrote:
> >> > The solution is to have a script that can tell you these two details:
> >> >
> >> > 1. What is the final value of ``*_enable''
> >> > 2. Which file assigns said final value
> >> >
> >> > If you have those two pieces of information, then unraveling a twisted
> >> > configuration is easier.
> >> >
> >> > [Re-]welcome my sysrc(8) script:
> >>
> >> While this is a very cool script, I have to wonder how far we have
> >> strayed if we require another tool to tell us how the system is
> >> configured. Surely we should be aiming for simplicity in our
> >> implementation and not something incredibly complex.
> >>
> >> After Jason's proposal, we would have the following list of configuration files:
> >>
> >> /etc/defaults/rc.conf
> >> /etc/rc.conf
> >> /etc/rc.conf.local
> >
> > What seems to be lost here is that the below two are "optional" not
> > something that should be created by anything other than the user who needs
> > that functionality. Yes having two of the below is a problem. Yes {name}
> > needs to go. But until there is something to replace it in a way that is
> > agreed on we cant get rid of the broken {name} implement.
> 
> The {name} implementation isn't broken, it just doesn't do what you want it to.
> 
> I would be hesitant to remove the {name} implementation, it's been
> there since the 5.x days. It's hard to say how many installations rely
> on it being there.
> 

Though I would like to I agree with that. You dint just introduce an 
interface and remove it later down the road with a long winded deprecation 
process. This certainly could be the start of that deprecation process.

"It just doesn't do what it is suggested to do" not what I want it to do 
by rc.conf(5) which is part of the reason why this patch came into play. 

You can't just provide a space to use and then suggest to the user that 
they only use certain undocumented names that are provided by rc.d/* 
scripts. It's a waste of their time thinking that they can just put for 
instance 'jail, jail1, jail2' in rc.conf.d and it'll work. It does not 
unless you start adding source this and that lines to the end of every 
file and that would not be right to suggest to the end-user either.

Though if it is documented well enough I do not see any fathomable reason 
why a user should not be allowed to make up a name that contains what they 
want to be in it. The rc.conf.d directory suggests its very use just as 
anyone would believe about usr/local/etc/apache22/Includes/*.conf.

Out of all the opposition yet I still have not seen a valid response of 
"what is wrong with letting the user decide how they name a configuration 
file?". I keep seeing the opposite of well you can do this and you can do 
that with shell scripting options. That shocks me as this is like stated 
before a user specified created and maintained directory.


-- 

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