Re: game-data-packager: why not?
Writing a bit brief here, I may need to elaborate later
On Fri, May 24, 2013 at 12:38:39PM +1000, Dmitry Smirnov wrote:
> As for "game-data-packager" -- it is a build system and not a very
> good one. Call me stupid but for few hours
Documentation is certainly not gdp's strongpoint.
> I couldn't figure out how should I _break_ my (traditional) packaging to
> produce the same .DEB file using "game-data-packager". But I don't want to
> follow uncommon work flow to package game data. Can "game-data-packager"
> build my package with minimum changes to debian/* files?
The way gdp is supposed to work is that you ship a .deb in gdp's binary
package which is complete with the exception of the bit that can't be
distributed for whatever reason, and gdp then inserts this bit into
the .deb "shell". So, if you have an existing .deb all ready, implementing
support in gdp is a case of adding your existing .deb stuff as a subdir,
and adding calls in the top-level Makefile to invoke whatever is necessary
in your subdir to build the .deb, or to clean up.
The existing targets have not used most of the Debian packaging heavy
machinery (e.g. debhelper) simply because they are trivially simple .deb
files. There's nothing stopping a new .deb being built with debhelper or
whatever (it would just need adding to gdp's Depends or Build-Depends).
However, if your existing .deb didn't do complex work in postinst or
whatever to fetch external data, how complicated does it become? The
ones we ship at the moment are utterly trivial, mere thin shells within
which the data will end up. The logic is all in the game-data-packager
scripts themselves.
> How to build a package from "game-data-packager" source tree without
> re-building it?
To be honest I just rebuild the lot every time. The whole lot is very small and
quick to build, and the Makefiles written such that things are not needlessly
rebuilt. So if I'm changing e.g. stuff relating to quake, repeated invocations
of 'make' (should) only rebuild things where source files have changed.
However, if you had a package 'foo' which was built as a standard debian source
package, 'cd foo && debuild'. As the list of supported games grows, perhaps
the large default and clean targets in Makefile could/should be broken up,
so it could be 'make foo' or 'make clean-foo' (or see below…)
> How to import/convert existing debian package to "game-data-packager"?
That's hard to answer generally, as it depends very much on what the original
debian package needs to do. 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.
> Why shall I produce a specific Makefile that doesn't look like normal
> debian/rules file?
The current Makefile has basically two targets, the default one (build)
and 'clean'. Perhaps it would be nicer if we made it more like a debian
rules file? I'm not sure. In the back of my mind was the idea of making
it less Debian specific (it could be useful on e.g. Fedora). Or perhaps
the Makefile could be moved to debian/rules. Perhaps it is not portable
since you'd need to slipstream into RPMs instead of DEBs and that would
outweigh the reusable bits.
If we ruled that out entirely we could move towards making it look more
like a typical debian package in places perhaps.
> IMHO ideally it could be just a wrapper over Debian toolchain to produce game
> data packages from normal packaging.
Arguably it does use the Debian toolchain, albeit at a layer lower than most
people are used to. One problem we have here is surprisingly few packagers
understand how packages actually work underneath things like debhelper. For the
existing (trivally simple) .debs, debhelper or even higher level tools seemed
like a real waste of time and resource. With gdp, most of the heavy lifting
takes place in the run time tools. But perhaps there's an application of gdp
that we haven't considered where the .debs do need to be more complicated. So
far they are nearly all just a control file, a copyright file, and that's it
(except for the non-free bit that gets injected later). 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 don't see an easy way to convert existing packaging to redundant
> "game-data-packager" build system and I doubt that such customised build
> system provides any benefits.
I don't see what you mean by 'redundant' here.
> Finally in my case one source package for game data shall produce
> dozen binary packages with their own descriptions and dependency
> relationships.
There are no source packages at present in gdp, but if you have that many
binary packages perhaps there's a need for there to be.
I think there is some kind of waterline, at which point it makes sense to
harness higher level tools and not reinvent the wheel. I don't feel we had
reached it with the simple .debs for the initial games I wrote support for,
but more complex schemes could well be above it.
If you've got proof-of-concept code up somewhere for your package I'd love
to take a look and think through what implications implementing it in gdp
would have, regardless of whether or not you'd use it, as it would help to
make gdp more robust and useful.
Reply to: