Re: game-data-packager: why not?
On 24/05/13 12:17, Jonathan Dowland wrote:
> The ideal case is you just throw away the
> existing package, not convert it at all, because all the logical bits
> you needed to fetch/convert data are already implemented. In practise
> every game that's been added to gdp has involved either implementing
> more utility functions or making adjustments to existing ones to
> accommodate new requirements.
If I ever have time, I would like to make g-d-p sufficiently declarative
that it can have a GUI (probably Python + Gtk3, unless Jon has a strong
preference for some other language or toolkit) - ideally, each package's
"code" would eventually consist of a list of necessary files with their
checksums (possibly including alternatives if there are several
acceptable versions), some hints regarding where we can get them (free
download? retail CD? derived from another non-free file like the
download from gog.com? etc.), and how to fish them out of a
pre-generated or even pre-installed g-d-p package (to refresh the
packaging without re-obtaining the files).
The first attempt at this is more likely to look like this:
/---------------------------------------------\
| Select game: [Quake III Arena___________|v] |
|---------------------------------------------|
| There is no GUI for this game yet. Please |
| run "game-data-packager quake3" and follow |
| the instructions. |
| |
| /----------------------------------------\ |
| | smcv@archetype:~$ | |
| | | |
| | | |
| \----------------------------------------/ |
\---------------------------------------------/
... and then we can make games declarative enough to have a proper GUI
instead of the terminal widget, one-by-one. I would anticipate it
eventually looking more like this:
/----------------------------------------------------\
| Select game: [Quake III Arena_________________|v] |
|====================================================|
| Required: pak0.pk3 *Installed* |
| [Update packaging]|
|----------------------------------------------------|
| Required: Quake III Arena 1.32b *Not found* |
| Can be downloaded. [Download] |
| Files: pak1.pk3, ..., pak8.pk3 [Browse] |
| or: linuxq3apoint-1.32b-3.x86.run |
| or: q3apoint-1.32.exe |
|====================================================|
| Optional: Quake III: Team Arena *Not found* |
| Retail CD/DVD: Quake III: Team Arena [Scan CDs] |
| or: Quake III Gold |
| Files: mp-pak0.pk3 (from CD or _Steam_) [Browse] |
| or: setup_quake3_gold.exe (from _gog.com_) |
\----------------------------------------------------/
> We don't do anything with triggers yet, for example, perhaps
> there's a good reason for a data package to do something like that.
> I think we only added icons and .desktop files and things
> relatively recently.
I think it makes sense to keep the game-data-packager output as "stupid"
as possible - "tarballs with dependencies" rather than full Debian
packages - because once a g-d-p user has generated and installed the
.deb, they will probably never touch it again. (Ideally, g-d-p would be
able to "refresh" installed .debs from the installed files when
necessary, though.)
As much as possible should be in the game's distributable
contrib/non-free package, and in particular, if there are bits that need
"intelligence" or policy compliance, or could otherwise have fixable
bugs, they're better off in the archive.
For instance, in the quake package I install icons and .desktop files
for all of Quake 1, Quake 1 mission pack 1, and Quake 1 mission pack 2.
The mission packs' .desktop files use the TryExec feature to detect
which non-distributable data from g-d-p is installed, and I included a
no-op executable shell script in each "mission pack" so that it could be
detected with TryExec, rather than having the mission pack data contain
a .desktop file or icon.
> On Fri, May 24, 2013 at 12:38:39PM +1000, Dmitry Smirnov wrote:
>> Finally in my case one source package for game data shall produce
>> dozen binary packages with their own descriptions and dependency
>> relationships.
What's in these packages, and why are they separate?
At the moment, quake3-data contains files from two sources: the
freely-downloadable-but-vaguely-licensed update, and the
definitely-not-distributable retail CD. With hindsight, I think this was
a bug: we should probably have had "quake3-patch-data" and
"quake3-pak0-data", because they're produced from different "sources"
(and "game-data-packager quake3" should be willing to produce and
install either or both, depending what data you supply). We shouldn't
bother with separate packages for pak1 and pak2 (both part of the
patch), though, because when you download the patch, you get both anyway.
For Freespace 2, I can see that the "retail" game and the "MediaVP"
graphical upgrade ought to be separate data packages - the MediaVP gets
refreshed occasionally, whereas the retail game is a fixed-point. What
else? Is the editor separate, perhaps?
S
Reply to: