Bug#693277: Bug#677517: minetest 0.4 unstable version

[Vincent Cheng]

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 <mat8913ftw at 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