Bug#705077: 0ad: Configuration file *must* be under /etc

[Vincent Cheng]

On Wed, Apr 10, 2013 at 9:22 AM, Martin Quinson <martin.quinson at loria.fr> wrote:
> On Wed, Apr 10, 2013 at 05:44:56PM +0200, Ansgar Burchardt wrote:
>> On 04/10/2013 08:45, Martin Quinson wrote:
>> > On Tue, Apr 09, 2013 at 10:32:01PM -0700, Vincent Cheng wrote:
>> > If they are templates, they must go to /usr/share/doc. But that's not
>> > true: when I edit this file, and relaunch the game, I see the
>> > difference applied in the game. I did this:
>>
>> No, files that are used by the program (for example when it uses them as
>> a base for a file in ~/.config) must *not* be in /usr/share/doc.
>
> I meant "template" as in "example of file that you could copy and
> adapt", explaining that I argumented that they are no templates since
> the program use them.

Err, I was mistaken when I said "templates". AFAIU, 0ad does read
settings from /usr/share/games/0ad/config/default.cfg (if present; if
it's not there, 0ad will just ignore it), but users can specifically
choose to override some (or all) of the settings listed in that file
with a similar config file in $XDG_CONFIG_HOME.

>> > and then the game starts in windowed mode. The fact that ~/.0ad config
>> > files override /etc/ files seems quite usual to me, but do not change
>> > my feeling about config files out of /etc.
>>
>> As far as I know having default configurations in /usr that are
>> overriden by files in /etc or $HOME is allowed by the FHS. As long as
>> users are not supposed to change them at least.
>
> What bother me is that it is impossible to provide system-wide
> configuration in /etc. I have to use /usr for that.
>
> Or maybe I misunderstood the thing, and these file can be placed and
> edited in /etc also, restoring the good old hierarchy of overrides
>  [/usr]  ->  /etc  ->  ~

It's not that desktop applications ignore the FHS entirely, it's just
that it isn't very practical for (what are intended to be)
user-specific profiles and/or configuration for desktop applications
to be placed in what is intended to be a system-wide directory for
config files (/etc). That works well for your typical daemon running
in the background, but not so much for games. Hence the existence of
the Freedesktop.org's XDG spec [1] and associated standards like
$XDG_{CONFIG,DATA,CACHE}_HOME, which more and more desktop
applications now follow.

0ad's configuration/settings aren't actually intended to be modified
by changing /usr/share/games/0ad/config/default.cfg anyways; the
intent is for users to modify them in-game via a friendly GUI, which
saves these settings into some subdir in $XDG_CONFIG_HOME (which is
pretty standard for games, anyways). That's not to say that there
aren't any other ways to change 0ad's settings (e.g. modifying
/usr/share/games/0ad/config/default.cfg and treating it as a conffile
even when the header of said file says not to do so, or via
command-line arguments passed to pyrogenesis), but these are not
supposed to be treated as the canonical way of modifying and saving
settings that you've tweaked.

> I have the feeling that there is no system wide *conffile* in which I
> could specify that I want a windowed mode so that my edit don't get
> erased when the package is reinstalled. This seems to be a violation
> of the whole 10.7 section of the policy, particularly 10.7.2:
>
> | Any configuration files created or used by your package must reside
> | in /etc. If there are several, consider creating a subdirectory of
> | /etc named after your package.
> |
> | If your package creates or uses configuration files outside of /etc,
> | and it is not feasible to modify the package to use /etc directly,
> | put the files in /etc and create symbolic links to those files from
> | the location that the package requires.

So basically, all games (and other desktop applications) need to make
their config settings accessible as conffiles in /etc, and if they
don't it's an RC bug? All right, sounds like it's time for a mass RC
bug filing against the majority of the Debian Games team's packages,
as well as hundreds of other GNOME/KDE/other desktop applications. :/

Maybe we should try to get Freedesktop.org standards enshrined in
Policy (as a formality, since they're generally considered to be
standards already), but that's an awful lot of work too...

Regards,
Vincent

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html