[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFR: meritous



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: pgpyMxFwWIOoP.pgp
Description: PGP signature


Reply to: