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

Re: game-data-packager: why not?

(BTW, Jon, could you push your changes for version 33 to the Alioth
repository? Thanks!)

On Sat, 25 May 2013 14:12:41 +0100, Simon McVittie <smcv@debian.org> wrote:
> 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).

I've been thinking about this a fair bit as well, and I've come to some of
the same conclusions.

[Snip GUI.]

I like the idea, although the second screen seems a bit complicated to me. I
see two basic use-cases for g-d-p: "help me install this particular game",
and "help me install all the games I have that g-d-p knows about". As far as
acquiring the necessary files is concerned, perhaps it would be enough to
offer to scan a CD (or several, e.g. for The 7th Guest), scan one or more
GOG.com or DotEmu installation packages (thanks innoextract for the former),
scan a Steam installation, a previous g-d-p installation, or any other folder
the user would like. If g-d-p can handle downloading and applying patches (à
la quake3), do we need anything more directly in the GUI, instead of in
documentation? We could have a "tell me what's missing" mode too...

Listing specific files we're looking for in the GUI works for Quake-style
packages but not for others (ScummVM games for example).

> > 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.

I'm not sure that scales though (despite your nice engine/game/data
separation). One of the things I'd like to do is add support for ScummVM
games, since they can be a bit of a pain to set up; but there's a whole pile
of them, so it seems to me that it makes more sense to have the .desktop
files for instance in the game data packages rather than the scummvm package.

In any case a g-d-p-build package shouldn't have much in it beyond the
non-free files:
* control
* copyright
* changelog for policy
* README.Debian perhaps (to point back to g-d-p)
* a .desktop file
* an icon?
* preinst to handle some upgrades (as in the Doom packages)

I see your point about updating the smarts, and users not refreshing the
packages; I was thinking one way of handling that might be to have g-d-p
automatically create a local apt repository, that it could then use to update
the packages it generates, but that's quite likely overkill. (Although very
nice to have in when you think about it...)

One thing I'd definitely like to do is drop the intermediate .debs which are
shipped in g-d-p; we end up doing the same processing at build-time and
run-time, stuff like md5sums, repacking the .deb obviously... It would make
things easier for other contributors to understand I think, and bring things
closer to what they're used to from "classic" Debian packages: just provide
control, copyright, .desktop, some specific shell scripts perhaps, and some
sort of description file, and hey presto! No need for a Makefile in the
quake.mk style. (I'm working on it.)

> > 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.

I like that approach! It would work for Quake II packaging as well... I guess
it also explains the level of detail in your GUI mockup. I'm wondering though
if patching shouldn't be (at least by default) handled automatically and
without involving the user: as a user I'd like to just be able to say "here's
a CD (or whatever), let me play the game in the best possible way" and not
care whether there's a patch, whether it modifies files (so results in a
single package) or adds files, etc.

Incidentally I've pushed a first version of a music extractor to the
quake-music branch; it's not finished though, the resulting packages need
some work on the control file at least. (And this is what prompted the remark
about dropping intermediate .debs, since producing nice music .debs means
adding yet another Makefile.)



Attachment: signature.asc
Description: PGP signature

Reply to: