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

Re: game-data-packager: why not?

On 29/05/13 04:49, Dmitry Smirnov wrote:
> 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...

If g-d-p ever becomes "fully declarative" that might make more sense,
but in practice adding each new game has required adding more "core"
functions, which suggests that g-d-p has not yet reached a point where
this is realistic.

(Also, if everything is internal to g-d-p, then "breaking API" to add
new functionality isn't a problem: every supported game is in-tree and
can be updated.)

> Something like target "check" comes to mind, to check whenever we
> already have expected files by verifying their checksums before
> downloading...

At the moment, if you already have the downloadable file, you're
expected to pass it in as command-line input. If there's a mode where
files already on the filesystem from the package can be re-packaged
(analogous to dpkg-repack), I would expect it to be equivalent to
running g-d-p with appropriate arguments (and perhaps even implemented
by re-running g-d-p).

>> For the
>> existing (trivally simple) .debs, debhelper or even higher level tools seemed
>> like a real waste of time and resource.
> 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?

Normal Debian packaging deals with source code, a non-trivial build
process, converting upstream's "make install" into what we actually want
in the binary package(s), and setting up maintainer scripts.

game-data-packager-generated packages are much simpler: they don't
really have source code (they don't contain any files that aren't copied
verbatim into the .deb), don't have a build process beyond dpkg-deb,
don't have an upstream (so we can just make sure the files are already
in the layout we want), and don't have maintainer scripts.

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

My only concern about this is that keeping the .deb on the filesystem
*and* having it installed means you always have two copies of the data.
For something like Quake III Arena that's an extra 500MB (or more like
1GB if I get round to implementing Team Arena support).

Also, you're going to have to run g-d-p (or its hypothetical GUI) to
update the local repository anyway, at which point the same tool might
as well do the package installation?


Reply to: