I've split up my 0ad packaging as recommended previously. I've also taken the opportunity to do a few little things to prune my packaging, e.g. setting the maintainer in debian/control to the games team, appending "(debug)" to 0ad-dbg's short description, replacing every instance of
http://wildfiregames.com with
http://www.wildfiregames.com, changing the section that 0ad's man page belongs in. My packaging can be found in Debian mentors [1], or in the Debian Games' SVN repository [2].
I originally thought it would be more convenient for me as a maintainer if I combined 0ad's build and data tarballs together and uploaded it as a single tarball, but I hadn't thought of the fact that I would have to build and upload 0ad-data as well if I simply had to make an adjustment to 0ad's packaging, not to mention that it's probably a good idea to not touch the original source tarballs needlessly.
Here's a checklist of what still needs to be done, which I'm going to tackle one by one over the next few days/weeks:
- package libenet1.2, and replace 0ad's build dependency on libenet-dev with this new package
- package libmozjs185, and remove the spidermonkey code that's currently in the source tarball (this could be deferred until alpha 5 is released, since according to Philip, 0 A.D. hasn't been ported to work with it yet; for now, I guess we'll have to leave the spidermonkey code embedded in the source tarball)
- ensure that everything is accounted for in debian/copyright
- determine what, if anything, needs to be removed from the source tarball (the only thing I've removed so far is /libraries/fcollada/src/FCollada/FColladaTest/Samples/Eagle.DAE)
As for the fonts, since they aren't used during the build or at runtime, would it really be necessary to package them separately (is there any point in having an unused package in Debian's repositories)? Removing them from the source tarball would be a much faster alternative, unless upstream decides to set up a build system to convert/render those fonts at build time.
- Vincent