Bug#783030: vcmi: lookup path is does not follow Filesystem Hierarchy Standard

Sun May 3 00:11:30 UTC 2015

Control: forwarded -1 http://bugs.vcmi.eu/view.php?id=2189

I forwarded the suggestion to at least add the lookup path
/usr/share/games/vcmi to the existing lookup paths.

I also filed a bug about changing the default path to store data files but I
doubt they will accept it because the XDG is very explicit about how /usr/share
is to be handled: http://bugs.vcmi.eu/view.php?id=2190

Quoting Alexandre Detiste (2015-04-29 14:46:13)
> I feel when reading between the lines that it's what the FHS really had in
> mind, when it says:
> 
> | /usr/share : Architecture-independent data
> | ...
> | Specific Options
> | ...
> | The following directories, or symbolic links to directories, must be in /usr/share, if the corresponding subsystem is installed:
> | ...
> | games Static data files for /usr/games (optional)
> 
> As it's there in Debian, even if it's not explitely mandated, why not use it ?

it also turns out I was reading a different version of the FHS. I now see what
you cite in https://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.txt as
well as in http://www.pathname.com/fhs/pub/fhs-2.3.html#SPECIFICOPTIONS15

> Now about Debian: "dpkg -S /usr/share/games" will give me a lenghty list of
> some games that follow this rule, it's much more work to get a list of games
> that don't follow the rule (attached games.sh); and that glimpse is only
> applicable for the games someone has currently installed.
> 
> That gives me a list ("list | grep -v kde4 .txt"):
>  - all KDE games follow their own rules, at least that's consitent
> 
>  - cowsay: but is more a "other frivolous programs" than a game properly
> 
>  - doomsday: filed #783707, as it seams to be a 3-line patch
>                       ... but there is currently no uploader anymore
> 
>  - gootool: unofficial .deb

Don't make it part of your argument if it's not in Debian proper.

> 
>  - gnuchess: seems that overriding $pkgdatadir would be enough
> 
>  - scummvm & residualvm: they share their namespace with the
>          games that have been freed and are avaible as huge .deb
>          in Debian, like "Beneath a steel sky" etc...
> 
>          Some games are even split in different .debs,
>          /usr/share/scummvm/sky.cpt (needed by Beneeth..) is found in scummvm-data
>          That would be tricky to change.
> 
>  - and vcmi

I tweaked your script a bit to give an overview of all packages in Debian and
not only those that happen to be installed locally.

According to this command, there seem to be 1194 games in Debian.

grep-aptavail --exact-match \( \
	--field Section games --or \
	--field Section contrib/games --or \
	--field Section non-free/games \) -s Package -n | sort -u | wc -l

According to this command, 472 packages ship a /usr/share/games directory:

curl --location http://http.debian.net/debian/dists/sid/Contents-amd64.gz \
	| zcat | grep ^usr/share/games | awk '{ print $(NF) }' \
	| cut -d '/' -f 2 | sort -u | wc -l

And if one adds a couple of more exceptions to your initial script (see
attached) then one can find 198 packages in the games section which do not ship
their data files in /usr/share/games.

So while one might read the FHS as suggesting that games are strongly suggested
to put their static data in a subdirectory in /usr/share/games, in practice in
Debian this does not happen in 17% of the cases which is not an insignificant
portion.

> > 4. Deviating from upstream in where static game data is stored would not be
> >    good
> 
> If this game is patched in Debian to merely _add_ an extra lookup location;
> this couldn't hurt.

Only that for example people on platform A would say "just edit this file in
/usr/share/vcmi" and a person on Debian would say "what?? I don't have that
file!". For ease of usability it is great if all distributions store the data
at the same location. This is why the FHS is useful and this is why it is a big
deal to let Debian deviate from the other distributions which just leave the
vanilla upstream choice for the default location in place.

> For OpenTyrian, this was a local patch before it was accepted upstream:
> http://anonscm.debian.org/cgit/pkg-games/opentyrian.git/tree/debian/patches/data_dir.patch
> 
> A patch for Doom3 engine to look in a engine-agnostic folder.
> http://anonscm.debian.org/cgit/pkg-games/dhewm3.git/tree/debian/patches/01-changedatadir.patch

The second patch has nothing to do with storing data in /usr/share/games
instead of /usr/share.

> > Given this unclear situation, would deviating from upstream be worth it?
> Upstream reference is vcmibuilder, which put stuff in /home;
> some users have to run it (as root) with --dest /usr/share/vcmi
> to put data there.

Where do you see that vcmibuilder has to be run with root and --dest
/usr/share/vcmi?

> > Given how the situation is so not-explicit in the FHS I even wonder how to
> > convince upstream to change to something the XDG doesn't even mention in
> > the first place...
> I would say the XDG completes the FHS, not replace it,
> so all the "obvious" stuff (/bin , /lib ...) is left out.
> 
> This is not absolutely needed to convince them,
> this only makes packaging easier with one patch less to refresh.
> 
> Most upstreams agrees when the gains are clearfully explained.

"gains" as in plural? What would be another gain for upstream besides following
FHS recommendations (and a XDG violation)?

> > Thus setting the severity to minor.
> It already was.

Whoops! :D Then I guess now I made extra sure that the severity really is set
to minor ^^

> > > By the way: I've added a rule to game-data-packager in git to let it
> > > repack HoMM3 data in ~/.local/share/vcmi in a .deb that can be installed
> > > system-wise.
> > 
> > This is awesome! Is there anything I can do from the vcmi side to integrate
> > this or make it nicer to use? Any examples I could follow of other packages
> > using game-data-packager in a similar way?
> 
> You could set a Recommends: or Depends: heroes3-data | game-data-packager,
> so that deborphan doesn't tell users to remove generated heroes3-data.
> 
> Of course this pull-in g-d-p if the data hasn't already been
> packaged/re-packaged.

I'd like to document how the user would use g-d-p for vcmi in the vcmi
README.Debian. Could you write a small blurp of what command to run that I can
put in that file or point me to an existing writeup for another game?

I'd also like to try this out myself.

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: games.sh
Type: text/x-shellscript
Size: 1338 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20150503/1f9b7dac/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: special.gz
Type: application/gzip
Size: 142469 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20150503/1f9b7dac/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20150503/1f9b7dac/attachment-0001.sig>