[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: OpenRC as Init System for Debian



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.


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

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



Reply to: