(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.) Regards, Stephen
Attachment:
signature.asc
Description: PGP signature