Re: RFC: OpenRC as Init System for Debian
On 05/11/2012 04:04 AM, David Weinehall wrote:
> On Fri, May 11, 2012 at 02:44:45AM +0800, Thomas Goirand wrote:
>
>> On 05/10/2012 04:52 AM, 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.
>>>
>>>
>> I agree 100% with the above.
>>
>> On 05/10/2012 05:22 AM, Uoti Urpala wrote:
>>
>>> 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.
>>>
>>>
>> No, it's because this way, I am warned by the package manager of a change
>> on the default file, and I can merge by hand when I see it. Otherwise, you
>> are silently changing the default, and potentially, I will miss the new
>> options.
>>
>> Besides this, configuration files in /etc is written in the stones of
>> our bible^Wpolicy-manual.
>>
> Has anyone argued for having the configuration files anywhere else?
> It's all in the semantics of course, but to me, the configuration files
> are the files that the administrator changes to change a configuration.
> The files that go in /lib are the defaults. If the admin wants to
> override something they do so in /etc, just like before.
>
From: http://en.wikipedia.org/wiki/Configuration_file
"In computing, configuration files, or config files configure the initial
settings for some computer programs. They are used for user applications,
server processes and operating system settings."
The fact that these files are in /lib and shouldn't be touched by the admin
doesn't make them less configuration files. They still match the above
definition from Wikipedia.
> If the old file in /lib isn't equal to the new file being installed to
> /lib, and there's a user supplied file in /etc rather than just the
> default (which would only include the version in lib), then prompt the
> user. If the user is running a non-interactive upgrade, fire off an
> e-mail or something. For any major changes to the /lib files (stuff
> that are likely to trigger user actions), NEWS.Debian should of course,
> as usual, contain a heads up.
>
No need to explain again, again and again the same thing. We did understand
what your point is, but still, we don't agree with you and Uoti. Move on.
> Just because something isn't supported currently in our tools doesn't
> make it impossible to support it.
The very reason why our tools don't support it, is because *we don't
want it*.
It's designed like this on purpose, and we are happy with the way things are
right now.
Why can't you implement something like amavis, grub2, or apache are doing?
Especially Amavis, where the default config is a conffile, but you can
override
what you need by using a higher number in the file name.
It works well, it is integrated with Debian and the way things work...
> And debian-policy isn't set in stone.
> Otherwise it wouldn't have last been revised in February 2012 :)
>
The debian-policy maybe, but the FHS, and config files in /etc *is* a very
strong policy that you will not change in Debian, and for very valid
reasons already described in this thread.
Thomas
Reply to: