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

Re: -data packages and recommends?



On Thursday 14 February 2008 12:54:31 pm Simon McVittie wrote:
> On Thu, 14 Feb 2008 at 18:20:54 +0100, Miriam Ruiz wrote:
> > 2008/2/14, Ivan Vucica <ivucica@gmail.com>:
> > >  A good example are multiple Doom implementations that were present in
> > >  Debian. They all used same data files, right? At least they should
> > >  have. So, making the -data package for Doom depend on, e.g., prboom,
> > >  would actually force users of other implementations to have prboom
> > >  installed as well.
> >
> > That's something ideologically complex, as you might be able to handle
> > data and games separately:
> >
> > 1) The game engine uses the data, but it could use different data
> > (Doom, Quake, Frets on Fire) to play the same game with different
> > "worlds".
> > 2) The data "uses" the game engine to be played, in the same way that
> > a Python script "uses" the python interpreter to be executed. A
> > dataset could be used from different programs (Doom or Quake worlds,
> > Ultrastar songs, FoF songs)
>
> Since the "identity" of a game is all about the gameplay, graphics etc.,
> it might seem to make sense for the .desktop files (and possibly also
> wrapper scripts in /usr/games) to be per dataset rather than per engine,
> so your GNOME menu or whatever has separate entries for id Doom and
> Freedoom, id Quake 3 Arena and OpenArena, and so on. If the engines are
> basically interchangeable but just have some versions that are "better",
> they could perhaps use alternatives.
>
> As I understand it, the Openarena engine is basically just icculus.org
> Quake 3, right? If it is in fact 100% "gameplay-compatible" with the retail
> Quake 3 Arena, I could see an argument for having this packaging scheme:
>
> ioquake3-engine (arch-dep)
>     Contains /usr/lib/games/ioquake3 and /usr/share/doc/ioquake3-engine
> only Recommends: openarena | quake3-data
>
> openarena (arch-indep)
>     Contains /usr/games/openarena (wrapper script that runs
>     /usr/lib/games/ioquake3/ioquake3 with appropriate arguments), .desktop
>     file, and free data
>     Depends: ioquake3-engine
>     Provides: quake3-data
>
> quake3-arena (arch-indep, non-free)
>     Contains /usr/games/quake3 (very similar to /usr/games/openarena),
> .desktop file, a copy of the patch pk3s (if they're distributable), and
> scripts that grab pak0.pk3 from a retail CD or other source (plus the patch
> pk3s if they're non-distributable)
>     Depends: ioquake3-engine
>     Provides: quake3-data
>
> urban-terror (arch-indep, non-free)
>     ... like openarena again ...
>
> world-of-padman (arch-indep, main? non-free? dunno)
>     ... like openarena again ...
>
> Obviously, if a game has forked the underlying engine then it might need
> its own engine package (Urban Terror has ioUrbanTerror, an ioquake3
> fork, but is runnable on retail Q3A so presumably it'd work on stock
> ioquake3; World of Padman I don't know about).
>
> Something to think about, anyway.
>
>     Simon

So in this case (as I understand it) , a game's package relationships could go 
something like:

game (binary-indep)
   Will contain the .desktop file and any game specific scripts or other game
   specific stuff.
   Depends: everything to play this game.
   Suggests: game-extra-{music,levels,maps,. . .} (basically, all extra
   stuff that Enhances this game).

{game,generic}-engine (binary-arch)
   Contains the engine to play a game.
   Recommends: game1 | game2 | . . .

game-data (binary-indep)
   Contains the binary independent data to play the game
   Recommends: game

game-extra-{music,levels,maps,. . .} (binary-indep)
   Any other package that could enhance the game, but not really necessary to
   play the game.
   {Depends,Recommends}: game-data
    (Once Enhances is properly supported) Enhances: game

Just a thought anyway.

I thinking of doing this for warsow and alien-arena (whenever I get around to 
packaging them again).

-- 
Regards,
Andres


Reply to: