Re: game-data-packager: why not?
Hi Jonathan,
Thank you for detailed answer.
On Fri, 24 May 2013 21:17:15 Jonathan Dowland wrote:
> 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).
Very interesting and now thanks to your explanation it started to make
a lot more sense to me. I'll definitely try to build a package using
this technique.
> > 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…)
I think to make (game-)data-packager more useful it would be nice to
make it modular i.e. (re-)design its interface to allow installing
plugins somewhere to
/usr/share/games/game-data-packager/{my-game-data}
by third-party packages rather than update game-data-packager every
time to introduce support for yet another game data package...
> > 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.
I see, thanks.
> > 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.
Something like target "check" comes to mind, to check whenever we
already have expected files by verifying their checksums before
downloading...
> > 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 think traditional heavy-weight debhelper-style generation of
packages makes sense for most developers... Is it just easier to
understand because workflow is more traditional?
Resource waste is just about slightly longer package building while
most of resources would be spent for maintaining, downloading
etc... I'm not too concerned whenever I'll need additional ~30 sec to
produce a .DEB file... But I see your point and I agree that debhelper
can be overkill when there is no need for it.
> > 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.
Sorry I meant redundant to debhelper & tools... But my words were not
well chosen as it seems that word "alternative" fits better...
> > 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.
Makes sense.
> 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.
Thank you, some time later I might invite you to evaluate some
experimental ideas in that area... I'm thinking that modular design is
a way to go to allow maintainers to install supporting data for
game-data-packager. I can imagine alternative way to ship some
metadata to allow generation of .DEB packages with game-data-packager
by providing necessary information with game engine package.
Also it might be interesting to try installing generated packages to
local repository to allow semi-automatic upgrades with apt-get. That's
just an idea without proof-of-concept implementation...
Thank you.
Cheers,
Dmitry Smirnov
GPG key : 4096R/53968D1B
---
Truth — Something somehow discreditable to someone.
-- H. L. Mencken, 1949
Reply to: