Re: vavoom_1.32-1_i386.changes REJECTED
On Mon, 17 Oct 2011 at 15:18:35 +0100, Jon Dowland wrote:
> Most if not all doom engines are DFSG free, but depend on game data. That can
> be satisfied via freedoom which *is* DFSG free, but in all likelyhood the vast
> majority of users are going to want to package up commercial data, which they
> do so via game-data-packager.
...
> I feel not recommending GDP from main is doing a disservice to the
> majority of our (doom package) users.
I'm sure you've seen enough rambling from me about why the Quake 1 and 3
packages are the "shape" they are - it occurs to me that following the
same approach would solve this.
I'd advocate having "doom" and "doom2" contrib packages that specifically mean
"Doom/Doom II, the well-known proprietary games by id Software" (and not
"a game in the style of Doom which may or may not be the real one"), depending
on an engine and some appropriate data; then the engines could drop their
dependency on data and their menu entries (or perhaps flag their menu entries
as NoDisplay by default), and be treated as an implementation detail of
the "id" game.
On the Free side of the fence, it seems freedoom and freedm already each
provide a wrapper script and menu entry and depend on a suitable engine, so
you're halfway there - only the proprietary side remains.
This approach does mean you have to choose a "best" engine to install by
default if a contrib/non-free user does an "apt-get install doom", which
isn't necessarily an obvious decision. "apt-get install quake" will currently
give you quakespasm, because that's an actively maintained engine that
limits itself to following the general "style" of unmodified Quake;
but we could easily have decided that nice lighting is more important
than looking like "traditional" Quake, and gone for darkplaces instead.
> GDP exists soley for this task and thus goes to contrib, despite itself being
> entirely free software. (It could be used to package up free software as well
> as non-free. Perhaps it should be moved to main?)
I think it's reasonable that g-d-p is in contrib - yes you could theoretically
give it support for Free data, but the only legitimate reason I can think of
would be data-sets too big to package (flightgear? vegastrike?), and
data.debian.org would probably be a better solution for those.
S
Reply to: