On Wed, Apr 10, 2013 at 9:22 AM, Martin Quinson <martin.quin...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org