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
anyway
* 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
Related:
* 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: