Re: RFC: OpenRC as Init System for Debian
Josselin Mouette <joss@debian.org> writes:
> Le vendredi 11 mai 2012 à 11:25 +0200, Gergely Nagy a écrit :
>> Thomas Goirand <zigo@debian.org> writes:
>> > 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.
>>
>> Can I point you to /usr/share/glib-2.0/schemas/,
>> /usr/share/gconf/defaults and similar?
>>
>> These are by the above definition, configuration files. Yet they are not
>> under /etc. They are used to load the initial configuration of software,
>> and can be overridden elsewhere (funny thing is, the gconf defaults can
>> be overridden with stuff in /var/lib/gconf/debian.* - even the overides
>> are outside of /etc!).
>
> Utterly wrong. The stuff in /var/lib/gconf is autogenerated, and any
> changes you do in it will not be preserved.
> The system administrator’s overrides have to be put in /etc/gconf.
Please read the "by the above definition" part. I know very well these
are not configuration files, the same way /lib/systemd/system/ stuff
isn't, either.
I'm glad it can be overridden in /etc too, but that wasn't the point.
>> Can we fix these first, where not even the overrides are in /etc, let
>> alone the defaults? Please?
>
> Can we get rid of useless babbling on debian-devel? Please?
Perhaps if you'd read what I was replying to, you would have noticed
what I was attempting to do: show that how silly the configuration file
definition quoted before was.
>> And in etc-overrides-lib, config files still remain in /etc. Its just
>> the defaults that live elsewhere. That the defaults are files, and are
>> under /lib, is an implementation detail, similarly how gconf defaults
>> live under /usr/share/gconf/defaults.
>
> There is a huge difference between gconf, for which you can set one
> specific setting in /etc, overriding the default in /usr (and in a way
> that will not break the application if the schemas change), and
> systemd/udev, which require to copy the *entire* file, leaving behind
> any improvements that could made to it in ulterior versions.
Not entirely true. You can override parts of the file too, without
copying: include the original. This doesn't let you override everything,
but for a lot of things, is good enough.
For the rest, well, it's a bit of inconvenience, but nothing that can't
be fixed with a clever script to warn about the original files changing.
--
|8]
Reply to: