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