[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#689824: RFP: yquake2 -- Yamagi Quake II - Enhanced client for Quake II

On Sun, Oct 06, 2013 at 11:23:14PM +0100, Simon McVittie wrote:
> I'm not sure that "download, checksum and compile source code from
> github" is something g-d-p should be doing, until/unless it's translated
> into a language where complex tasks are a bit more maintainable
> (probably Python).

I just thought I'd write something briefly about the Python angle, as I
don't think I contributed to the last discussion. I am very much in
favour of trying to do this, in fact I started trying to do it in 2009:
my first stab is in the 'gui' branch, which is a bit of a mess of
commits and merges of a (now deleted) yaml branch. I was mostly
interested in trying to specify and write declarative descriptions of
the dependencies and steps needed to do stuff. Then, the tool could
run some steps in the background whilst other steps were waiting on
user prompts, etc. The tool being written in a better language and
having a GUI were secondary at the time.

Anyway, it's no doubt bit-rotten beyond use now, and it would have
been gtk2 anyway (and probably glade rather than gtkbuilder). If I
were planning to have another stab as a solo person, I'd probably go
for QT this time, but I don't have strong feeling one way or another,
and I imagine GTK3 would be a smarter choice for others. I'd love to
have another crack at the declarative end (is YAML still a sane
choice on that score, I wonder? Seems to be…)

Another pie-in-the-sky thing would be to make the Debian stuff more
pluggable so this could be re-used on top of Fedora or Red Hat or
whatever. At the moment of course, it's Debian-ness is very deeply
inherent. Perhaps something to have in mind if a rewrite gets off
the ground.

I quite like the quake2-scheme of having expanded deb contents, rather
than template, placeholder .debs, installed into
/usr/share/games/game-data-packager: A side-effect is I think this
would be more "portable" wrt the above suggestion as well. (translating
a control file into RPM spec metadata is perhaps an easier job than
depending on alien and/or trying to do the same job)

Finally, since I'm ranting on about gdp: I think we need to either have
a rule of thumb that each 'target' generates precicely one .deb, or
alternatively not have that rule but handle the discoverability of
one target:many debs better. I'm generally in favour of the former
and may play around with some patches to split out the music and MPs
from quake and the music from quake2 (perhaps similary to how there's
a lib/doom-common) and see how legible the result is.

Reply to: