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?
S
Reply to: