Re: RFC: OpenRC as Init System for Debian
On Thursday 10 May 2012 19:53:18 Uoti Urpala wrote:
> George Danchev wrote:
> > On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote:
> > > Steve McIntyre wrote:
> > > > No, really - please *do* do this. The fact that a lot of the software
> > > > coming out of RedHat development seems to be designed solely for
> > > > their use, including working around the missing/broken features of
> > > > RPM, is seriously annoying. Configuration belongs in /etc, we know
> > > > this. We have a well-designed and implemented set of tools in Debian
> > > > based on that standard.
> > >
> > > Machine-specific configuration belongs in /etc. The default behavior of
> > > the tools doesn't.
> >
> > For some reason or another the vast majority of applications have not
> > been following this approach. I'm not going to argue whether is makes
> > sense or not.
>
> The reason why most old applications do not follow that approach (at
> least not yet) is pretty obvious: their authors never considered it.
> etc-overrides-lib semantics have only become a seriously considered
> alternative fairly recently.
Implying that a fairly simplistic semantics of providing two distinct
directories with configuration files, has never been considered for the last 40
years and painting it as a revolution in the application development is naive,
at best.
> > > Josh Triplett provided multiple technical reasons why etc-overrides-lib
> > > is preferable. The ONLY technical reason you gave to prefer traditional
> > > conffiles was that there already is a "set of tools" for that in
> > > Debian.
> >
> > Your comparison is misguided.
>
> Which comparison are you talking about? From your following text it
> seems you mean the comparison between 1) criticizing Red Hat for
> (allegedly) letting packaging system limitations affect the choice of
> configuration format and 2) saying Debian should choose its preferred
> configuration format based on the limitations of its packaging system,
Let me tell you a secret: Debian should not decide whether or not tens of
thousand of applications follow a particular style of reading their
configuration files. This is in the realm of application development and anyone
should be free to choose their style. It would be a segregation if Debian bans
applications simply because their style of reading configuration files looks
funny... and Debian does not segregate. This is not a secret.
> though that comparison does not appear in the text you quoted.
>
> > The vast majority of applications do not follow etc-overrides-lib (some
> > will never follow) so their configuration files should be properly
> > managed as well, and dpkg's conffiles facility, dpkg's maintainer
> > scripts in conjunction with things like ucf and debconf are quite
> > powerful mechanisms to employ which have been proven for the last
> > decade. Contrast this to the rpm systems trashing locally modified
> > configuration files in /etc/ for the last decade. It is also trivial for
> > the debian packages to contain default configuration files so users and
> > tools could refer to them on demand, and this has nothing to do with the
> > packaging system itself.
>
> You're pretty much just saying that dpkg and helpers like ucf have
> implemented better functionality than rpm. I don't see how that's
> relevant to the discussion. I don't think it makes the above comparison
> any less valid. And generally, I don't think the packaging system issues
> would be so difficult that they should have a major influence on what
> configuration model to use.
What I was saying, I already wrote. Retelling it wrong is useless.
> > OTOH, applications following etc-overrides-lib happily run on Debian
> > systems in the way they run on others. It is not like the semantics of
> > separating the default and locally modified configuration files in two
> > directories is some sort of giant invention, never heard of before. It
> > is also trivial to guess that their configuration files could also be
> > managed by calling tools from dpkg's maintainer scripts in order to
> > communicate with the user or provide assistance
>
> Yes, nobody has brought up reasons why this wouldn't work.
Now, the hard work remains: teach all applcations out there to follow the etc-
overrides-lib _semantics_. Sure, thing, I'm thrilled, at all.
--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Reply to: