Re: RFS: zdoom
Hi Jon,
----- Ursprüngliche Message -----
> Von: Jon Dowland <jmtd@debian.org>
> An: debian-devel-games@lists.debian.org
> Cc:
> Gesendet: 20:06 Dienstag, 6.September 2011
> Betreff: 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.
I agree. I had hoped that I would find the time to add hexen and strife to g-d-p
but I'm having trouble finding time to package zdoom in the first place.
> 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
Done.
> * 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.
Ok, i'll see if I can tweak the build stuff to get it to work without the embedded
software. It will take some time though, my regular work is keeping me really
busy at the moment.
> 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
Same applies here, I'll see what I can do...
> 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).
I've chaged the version to 2.5.0+debian1-1, is that ok?
> 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.
I added a comment to the copyright file.
Should I upload the new package to mentors or should I first try to get rid of
lzma, gema-music-emu, gdtoa, re2c and lemon? That could take some time...
Thanks for your help!
Johey
Reply to: