Hi Matthew, (First off: sorry Michael, I know I mentioned that I'd look into this "over the weekend" on IRC back in early December, but I ended up getting swamped with exams and now work (and my other packages). I'll try to free up some time for minetest, but at the moment I'll just give a review.)
On Thu, Jan 10, 2013 at 7:20 PM, Matthew Bekkema <mat8913...@gmail.com> wrote: > I've decided it would be much easier to package the latest upstream > tag than to do what I was attempting earlier (package their latest > commit) so I have started again and packaged their stable-0.4.4 > release and pushed the changes to my github repo. > > I've also updated the watch file but it still needs work because uscan > thinks that 0.4.dev-20120122-1 is the newer than 0.4.dev-20120606. - I've fixed the watch file: version=3 opts="dversionmangle=s/\+dfsg//g" \ https://github.com/celeron55/minetest/tags .*/(\d[\d\.]+)\.tar\.gz - Just wondering, does minetest 0.4.x actually still build with libirrlicht-dev 1.7 in unstable? I tested the current version of minetest in unstable when I uploaded irrlicht 1.8 to experimental, and it ended up with a FTBFS (bug #693277). If minetest 0.4.x requires irrlicht 1.8 rather than 1.7.x, please bump the build-depends on libirrlicht-dev to (>= 1.8). - Why debian/patches/remove-useless-depends.patch? Are they actually useless, as in minetest doesn't need libpng-dev, libjpeg-dev, libgl1-mesa-dev, libbz2-dev installed, in order to be built? If so, they should be removed from debian/control. - debian/control: s/libjpeg8-dev/libjpeg-dev/ - debian/control: According to Policy 7.6.1 [1], minetest-common should not only declare a Breaks: relationship with minetest, but rather Breaks+Replaces:. - debian/copyright: Format line should be http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ instead of a draft DEP-5 version. Also, include the full text of WTFPL for util/minetestmapper.py; "see COPYING for more details" isn't good enough since COPYING isn't even installed into the packages. - If upstream doesn't provide changelogs in the source tarball, and if it can't be generated at build time, I would suggest not including the upstream changelog at all rather than dumping it in debian/. You can just ignore lintian's no-upstream-changelog tag, if that's what you're concerned about. - Usually game packages (i.e. the package that contains the actual executable) declares a Depends: on their -data/-common package (i.e. all the arch-indep files), and the data package either Suggests: the game binary package, or doesn't declare any relationship with it...not the other way around. I can't find any Policy excerpt that enforces this, but I find it strange that minetest-game-{minimal,full} Depends: on minetest, and not the other way around. A game typically requires its data files to function properly, and often just fails to run/crashes without its data; on the other hand, data packages can be installed standalone, and are not inherently broken without the game itself (it's just a waste of disk space, really). - This is more just an opinion than anything else, but I don't really think it's necessary to split the game data into minetest-game-minimal and minetest-game-full. In debian/control, -minimal and -full are always listed together in the package relationships (there's no distinction between the two packages amongst the various relationships between all the binary packages), and both packages are already quite small in size. I just don't see any advantages to splitting them up that offsets the added complexity to the source package. Regards, Vincent [1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org