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

Sun May 3 08:47:30 UTC 2015

Le dimanche 3 mai 2015, 02:11:30 Johannes Schauer a écrit :
> I forwarded the suggestion to at least add the lookup path
> /usr/share/games/vcmi to the existing lookup paths.

Thanks! I'm now subcribed and monitoring those there too.

> 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

vcmbuilder does this:

| if [[ -z "$dest_dir" ]]
| then
|         if [[ -z "$XDG_DATA_HOME" ]]
|         then
|                 dest_dir="$HOME/.local/share/vcmi"
|         else
|                 dest_dir="$XDG_DATA_HOME/vcmi"
|         fi
| fi

It never tries to write in /usr by default.

>Where do you see that vcmibuilder has to be run with root and --dest
>/usr/share/vcmi?
It has to if somewant want a system-wide installation;
but it's not the default.

> >  - gootool: unofficial .deb
> 
> Don't make it part of your argument if it's not in Debian proper.

It came up on my list, so it needed an explanation;
most of these unofficial .debs are half broken and
make dpkg/reprepro/lintian complain a lot anyway.

I guess what Debian really needs is a specific section
for localy generated/localy installable packages.

Where "local" can either mean: 1 computer / 1 household / 1 company.

Then aptitude, equivs-control, vrms, "my version of games.sh",
could be patched to support this "local/<stuff>" section 
in a specific way and make it differ from (free)/contrib/non-free.

Simon McVittie came to the same conclusion for the
packages generated by G-D-P:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783817

> 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.

Wow, that's impressive what can be done with these QA tools :-)

> 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.

I've added /usr/share/gnome/help too, still running.

> 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.

Some things are not really games, but more "educational", like tuxtype, childsplay, 
mathwar, ... some might think the same from chess games...

While I really don't want to go mass-filling bugs for this; an extra
reason to consider is that budget-minded people can usually set-up a nice
PC with / on a cheap SSD (the 32 or 64Gb ones) and /var & /home
on a cheap-but-slow HDD. Now if more and more games are installed
in /usr/share/games, this would fill the SSD; 
and maybe /usr/share/games would need it's own partition too.

So the only game I would review in detail on this list is gemrb:
"Open-source engine to run Baldur's Gate, Icewind Dale and Planescape: Torment",
that needs huge datasets to work.

> > > 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.

Upstream explicitely expects that this directory can be patched:

I guess this Wiki could point to G-D-P, but I don't want to feel
intrusive and won't add it myself.

> > 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.

Indeed, just to point this can be patched to make the game fit better in Debian.

> > 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)?

Some other gain: their game don't get patched a little differently on each distro

> (and a XDG violation)?
This would really need to get explained there :-)

Arx Libertatis (yet another engine) does it right,
it searches for "games/arx" & "arx" at each XDG_DATA_DIR location.

http://wiki.arx-libertatis.org/Data_directories#Data_directory

> 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?

While it is advertised, vcmibuilder can't read iso files;
here is a patch; reword it as you like.

> I'd also like to try this out myself.

It's in sid now.

The "unknown" list of Popcon says there are already 2 users ! :-)

Cheers,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: readme.patch
Type: text/x-patch
Size: 726 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20150503/d9fa6f17/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20150503/d9fa6f17/attachment.sig>