Re: Packaging data files alternatives
Am 2011-09-01 13:42, schrieb Simon McVittie:
> On Thu, 01 Sep 2011 at 11:42:07 +0200, Emmanuel Kasper wrote:
>> I hijack this thread because I have a related question. I am somehow
>> working on a package gnome-video-arcade ( something like a games
>> catalog browser ) which is greatly enhanced by using extra catalog data
>> files.
>
> Is g-v-a main or contrib? How important are these data files for its
> functionality?
>
> Perhaps you could Suggest them (or if they're more important, Recommend
> or Depend, and move g-v-a to contrib) and put them in non-free?
> If they're freely redistributable, you probably don't need to resort to moving
> them off Debian infrastructure altogether; non-free would probably be OK.
g-v-a itself is in contrib, as it is a frond end for a non-free game
emulator ( mame )
As said, one maintainer refuses to put a license on his data file. The
file is freely downloadable, but without any kind of copyright, and
(modulo IANAL ), if you don't allow redistribution, then All rights are
Reserved.
For my personal use, I find these data files quite useful, as they
create categories, sub categories, number of players supported fields,
and all kind of useful meta data for the games. Without these data
files, it is like using apt-get without the package description field.
>> 1. write a downloader script to get this files, package the downloader
>> script. The script download the data files in
>> /usr/local/share/gva-data-whatever by default ,which is the path
>> gnome-video-arcade would look for them.
>> ( As an alternative the downloader script could be distributed with
>> gnome-video-arcade )
>
> For a GUI thing, letting each user do this via the UI (automatically
> write them to a subdirectory of g_get_user_data_dir (), and read from
> the same subdirectory of g_get_user_data_dir () followed by
> the same subdirectory of each of g_get_system_data_dirs ()) seems the best
> way, tbh.
If you're doing this sort of thing, make sure there is nothing that
could be
> put in these files that would compromise user or system security or privacy
> (in particular, if they can cause arbitrary code execution by the user,
> that's bad).
>
Use of the extra data files on gva is enabled by a configure switch with
a path provided at compile time. However even if it is compiled with the
switch on, it will works flawlessly with the data files.
I have understood that for two of these files, g-v-a uses the glib
GKeyFile functions for parsing .ini files, for the third one, a custom
written parser, and everything is put into a sqlite database before
being read at execution time.
I would then think the risk of arbitrary data execution here is small,
but I am definitively not a specialist of the topic.
Manu
Reply to: