On 05/02/2008, Dylan R. E. Moonfire wrote: > Sorry about that. The package name is 'meritous' not 'mertious', I > keep misspelling it but the package name is correct. OK. Specifying a fixed subject. Direct link to the source package: http://mfgames.com/debian/dists/unstable/main/source/meritous_1.2+dfsg-0pre2.dsc Some items to work on follow. Binary package, lintian reports: ,---- | I: meritous: arch-dep-package-has-big-usr-share 3460kB 95% | I: meritous: binary-has-unneeded-section ./usr/games/meritous .comment `---- The first one indicates it might be interesting to split the packaging meritous + meritous-data packages, the second being arch-independent. The second sounds like you shouldn't call “strip” directly, but rather let dh_strip do the job itself. I guess it detects the binary is stripped, so doesn't act at all, but it could have been stripped further in case dh_strip would have done the job alone. Just a wild guess, though. There's also this file: ,---- | ./usr/share/doc/meritous/gpl.txt.gz `---- Looks like an extra license file to me, the copyright file is sufficient, you can drop this one. JFTR, your clean rule does its job, the diff is still clean after a binary build, then a source build. Now, source package. Version is 1.2+dfsg-0pre2. I'm not sure what the “0pre2” indicates. If that's a preview (release candidate) of 1.2, that might be 1.2~0pre2 or something similar. 1.2~pre2 might be what you want, since I guess the 0 was only there to make sure it sorts before a -1. So, if you're going to use 1.2~pre2 as upstream version (remember to rename your .orig.tar.gz accordingly), that would mean 1.2~pre2-1 for the version you mention in debian/changelog. You could add a Homepage field in the control file, as well as Vcs-* headers if you're maintaining your package in a publicly-accessible version control system, see [1], item 3 (debcheckout). 1. http://lists.debian.org/debian-devel-announce/2008/02/msg00000.html debian/docs: gpl.txt should be dropped, which would solve the point raised above. debian/menus: looks like “needs” wasn't adapted, was it? Although the filename is pretty clear about its goal, you probably want to document what your data_in_share.patch patch does. I'd suggest at least an entry in debian/changelog (which I usually find sufficient), but I've seen advised to also include a header in the patch itself, see “quilt header”. You may want to use some quilt options to make your patch look a bit nicer, like --no-index, --no-timestamps, -p ab, etc. FWIW, I'm using: ,----[ ~/.quiltrc ]--- | QUILT_NO_DIFF_INDEX=true | QUILT_DIFF_ARGS="--color=auto -p ab" | QUILT_REFRESH_ARGS="-p ab" `---- debian/README.Debian should be moved to debian/changelog (see the comment above, about documenting the patch). No need to explain that in this file, which is mostly intended for end users. debian/rules: nothing is done in the configure target, you probably might remove it altogether with the its -stamp. strip call, already pointed out above. The detection of whether a make clean call is a bit surprizing. Couldn't you just call make clean inconditionally? Ah, OK, I see. I suggest you forward it to upstream to rather use rm -f on these files, which makes it possible to call “make clean” at any moment. You could eventually replace it with the following call, which would make it obvious what is intended, until upstream fixes it: ,---- | find -name '*.o' -delete `---- still debian/rules, you might use .install file to handle the installation of these files, rather than calling “install” manually. I'm not sure how dh_fixperms might handle the permissions of files under /usr/games, maybe the ownership is set appropriately, I'd suggest you try something like that. (You could grep in pkg-games's trunk to see whether some other packages are using chown/chmod or --group.) It's also good practice to delete the unused dh_* calls. Note that you aren't calling dh_installmenu. You could also use one of the file shipped in the share directory as an icon (in the menu file). Personal taste: I wouldn't use “(TM)” after Debian in the manpage footer. I'm also quite unhappy with the default “but may be used”. I tend to rather use “and may be”, which makes the intention clearer (you probably want upstream to include the manpage, so that you can just forget about it). It might be nitpicky, but I've been asked by one of my upstream about a manpage I updated, which contained such a statement. It might nice to see how to support debug builds, that is: no stripping and no optimization (Policy 10.1). That might require some tweaks in the upstream makefile, so that you can specifying some flags from debian/rules (like "-g -O0" in C(C)FLAGS). I think it's all for now, let me know if you have any troubles, or when you have an updated package, I'll have it sponsored. Cheers, -- Cyril Brulebois
Attachment:
pgpxq_ZT_Edpy.pgp
Description: PGP signature