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

Re: RFS: zdoom

On Sun, Sep 04, 2011 at 03:51:10PM +0100, Johey Shmit wrote:
> I uploaded it to mentors, It would be great if you could take a l

It looks really good. Just one or two small things.

I'd suggest changes to the virtual package names used for Suggests: and
Provides:; specifically:

 * doom-wad | heretic-wad | game-data-packager, "promoting" doom-wad or
   heretic-wad above gdp; removing hexen-wad and strife-wad (these virtual
   package names are not yet provided by anything)

 * removing hexen-engine, strife-engine, zdoom-engine from Provides:.

If someone implements hexen or strife support in g-d-p, such that hexen-wad or
strife-wad are concrete packages, then it would make sense to add them back.
(it would be pretty easy to add hexen or strife support thanks to the
"doom-common" stuff, I added heretic in about 10 minutes).

Similarly, if someone is likely to actually use zdoom-engine, then it can be
added back: but in the mean time no need to bloat the package name databases.

There are several copies of embedded software that should be stripped from
the source archive:

 * bzip2, zlib, jpeg-6b; all of which the build links against external copies
 * lzma: which you don't currently link against or depend on, but I think is
   provided by liblz1/liblz-dev, can zdoom be linked against this?  Removing
   it may require some adjustment here and there
 * game-music-emu seems to be packaged as libgme-dev, can zdoom be linked 
   against this?
 * strictly gdtoa could/should be packaged separately but mozilla used to
   embed gdtoa and got away with it so let's not worry


 * tools/re2c and the package re2c. Can the package be used as a build
   dependency instead of bundling and building tools/re2c?
 * likewise for tools/lemon → package lemon

Once the above are stripped (or not); the *source* package version should be
marked to indicate it's been tampered with, such as with a suffix +debian1
(the '1' can be iterated if further changes are necessary).

The changes should then be documented in debian/copyright. (yeah, it's weird to
modify the orig source but document the changes in the debian bit).  Perhaps a
DEP5 "Comment:" field could be use to explain what was removed and why.  It
could also be a good idea to draw attention to the fact that fmod is bundled.

Jon Dowland

Reply to: