some review of pending g-d-p changes

Alexandre Detiste alexandre.detiste at gmail.com
Mon Apr 27 19:45:53 UTC 2015


Le lundi 27 avril 2015, 15:35:26 Simon McVittie a écrit :
> > Do you fear the doom2-masterleves .deb would hold back the gdp.deb ?
> 
> Yes [....]

Ah, ok so lets put back everything in one single package for now and
release this; doom2-masterlevels.py is only 11kb.

The package description for doom2-masterlevels can be pulled
back later from Git history if needed.

> Possibly; I was more thinking of things like the ability to ship the
> Cacodemon icon in g-d-p-support rather than copying it repeatedly.

doom2-masterlevels uses the icon from doom2-masterlevels-wad to avoid
one copy, but I see the point.

> Duplicating the changelog is actually good in a way, since it means that
> every .deb has *its own* changelog, rather than the changelog from a
> potentially different version of g-d-p.
Ok, I see it was a dumb idea :-)

While searching for ideas, I found that freespace2 ships unpacked source packages 
in his package, and users have to run debuild to get some locally generated .deb

The changelog there are a empty: I don't advocate that either.

http://anonscm.debian.org/cgit/users/onlyjob/freespace2.git/tree/debian/packages
http://anonscm.debian.org/cgit/users/onlyjob/freespace2.git/tree/debian/packages/freespace2-data-gog/debian/changelog


> I don't think we want to give
> game data packages a lockstep dependency on
> game-data-packager-support (= ${source:Version}).
That would make mandatory to repack everything at each g-d-p release :-( !


> We'd probably want to weaken the dependency on python3-gi and the Gtk
> gir stuff to a Recommends or even Suggests if the doom2 launcher was
> just part of a larger package, since they're only desirable if you
> *also* have doom2-masterlevels-wad.

It already dynamicaly check for (the contents of) doom2-masterlevels-wad,
and display a Gtk box if needed.

If we can't even know if "gi" is avaible,
we'd need this kind of error handling too ?

try:
   import gi
  gi.require_version('Gtk', '3.0')
  from gi.repository import Gtk, Pango
except:
   "display message with  zenity / kdialog / xmessage / dbus-notify"



BTW, Running through ssh without X forwarding also fails horribly for now:
+200 lines of warning & then it segfaults. 
I thought of checking for $DISPLAY, but that seems wrong.

> Alternatively, perhaps the generated packages should just hard-depend on
> game-data-packager (which in practice you will probably keep installed
> anyway)... 
As most .debs are not redistribuable, they would remain on a single computer;
this seems practical. And this could also be on a per-yaml/generated package basis
to avoid extraneous depedencies.

> and g-d-p is going to gain a Recommends on Gtk3 bits as soon
> as we do a GUI for it (or perhaps sooner and at Depends level, since I'm
> very tempted to depend on python3-gi for the necessary internal
> refactoring to make it asynchronous and hence GUI-friendly).

That seems much better that what I could handle without some direction:
some 'GUI' that looks like an old xcdroast with a huge terminal widget.

> 
> >> We could put a dummy executable file in doom2-masterlevels-wad and refer
> >> to it in TryExec in the .desktop file for the frontend, like we do for
> >> Quake III Team Arena (look in src:quake3)?
> > 
> > Would a symlink to /bin/true work ?
> > This way we don't even need to ship a dummy .sh
> 
> Yes, or a symlink to /etc/alternatives/doom would be even better. That
> way the TryExec would fail unless we had both doom2-masterlevels-wad and
> a doom-engine implementation, which is exactly what is desired here.

Ok !

So we have "ln -s /etc/alternatives/doom /usr/share/games/doom/doom2-masterlevels-tryexec"
in doom2-masterlevels-wad and
TryExec=/usr/share/games/doom/doom2-masterlevels-tryexec
in doom2-masterlevels.desktop shipped by gdp.deb

> If the difference is level of censorship rather than color/colour etc.,
> then yes, -en-censored- and -en- seem like better names. I would
> personally make -en- the default, unless the uncensored version is
> particularly gratuitous (I don't know the context here).

wikipedia says:
 It was also one of the first mainstream games to feature an uncensored sex scene,
 which was quite controversial at the time of release, despite merely being a few top-down viewed pixels.

I guess if you've got root password to install the generated .deb 
you're old enough to play the game.

Now it downloads a file it doesn't even need,
I'll disable the 'download:' for now.

tchet at antec:~/git/game-data-packager$ ./run dreamweb --destination /tmp  --no-compress
INFO:game-data-packager:downloading http://localhost/dreamweb-cd-us-1.1.zip
INFO:game-data-packager:extracting DREAMWEB.P01 from /tmp/gdptmp.dcyb_a_m/tmp/dreamweb-cd-us-1.1.zip
INFO:game-data-packager:extracting DREAMWEB.P02 from /tmp/gdptmp.dcyb_a_m/tmp/dreamweb-cd-us-1.1.zip
INFO:game-data-packager:extracting DREAMWEB.WAV from /tmp/gdptmp.dcyb_a_m/tmp/dreamweb-cd-us-1.1.zip
INFO:game-data-packager:downloading http://localhost/dreamweb-cd-uk-1.1.zip
generated "/tmp/dreamweb-en-data_1.1+41_all.deb"
tchet at antec:~/git/game-data-packager$

> I don't want a data structure called cksums (or equivalent) that does
> not (at least conceptually) contain the checksums for which the data
> structure is named :-)
> 
> Perhaps this is a sign that we should have
> 
> sizes:
>     666 doom.wad
Yes!

> the same way we've incrementally added support for increasingly
> horrible container formats.

Horrible, indeed :-)



More information about the Pkg-games-devel mailing list