Beginners packaging example from Debian Med sprint: pscoils
[For those beginners who would like to follow the explanation I'm
talking about what you get when your do
dget http://www.biocomp.unibo.it/piero/debpackages/pscoils/pscoils_1.0+20120128-1.dsc
]
Hi Piero,
thanks for preparing three packages in the Debian Med Sprint in
Southport. That's quite an amount of work for a packaging newbee and I
really appreciate your work. I will comment on your work step by step.
Some things are easy enouth for me to do in a rush just with these
comments and I mark this in the text with [Done]. Other bits I will
leave for you to do because its better if you just do it yourself by
following my advise to enhance your packaging skills when just doing
this.
As I told you the usual way to work on code is via Vcs (SVN or Git)
but the unavailability of Alioth will require workarounds like
Uploading to random http servers. I guess such workarounds will
not be needed but we can deal with this for now.
Further remark: Please be not afraid about the lengthyness of my
mail. I try to be very verbose for educational purposes and I try
to apply high quality standards. Some issues are minor and it is
no shame for a beginner be not fully correct in these things.
Now for the packages:
pscoils
-------
We do not need to keep dh_make template files, so please do an
rm -f debian/*.ex debian/*.EX
[Done]
to not blur the real things which are worth inspecting. An alternative
way to not even have these *.ex files in the first place is to just copy
the packaging of an existing package which is some kind of "similar" to
what you want to do.
I admit for a beginner it is probably hard to find such similar packages
but once you have a first package ready you most probably have your
first example for the next packaging, right?
As a further tip if you are specifically seeking for modern Python
packages where modern in this case means using the most recent
and recommended tools and not learning from historic outdated
stuff which needs updating, a good seeking strategy would be to
check out SVN and do a
grep "dh.*python2" trunk/packages/*/trunk/debian/rules
Currently this reveals 16 packages which might serve as usefull examples
to adopt from. As a homework I would like you to at least have a quick
look into two random ones of these.
Now working down the set of files I found
$ cat debian/README.Debian
pscoils for Debian
------------------
<possible notes regarding this package - if none, delete this file>
-- Piero Fariselli <piero.fariselli@unibo.it> Sun, 29 Jan 2012 10:42:19 +0100
You see it makes sense to have a look into any of these dh_make examples
and do as advised. I have no idea whether you want to tell your users
something about some Debian specific details of this package which would
belong to this file (even if this somehow seems to be a perfectly hidden
secret to user and I rarely have heard that users are noticing this file).
$ cat debian/README.source
pscoils for Debian
------------------
<this file describes information about the source package, see Debian policy
manual section 4.14. You WILL either need to modify or delete this file>
Same as above but targeting at developers trying to reproduce what you
did. If there is nothing special to mention just delete this file.
$ grep Closes debian/changelog
* Initial release (Closes: #nnnn) <nnnn is the bug number of your ITP>
So you did not yet filed an ITP bug, right? Please read more about this
in Debian Med policy. If something might remain unclear please ask here.
$ grep "DM-Upload-Allowed" debian/control
You did not set this field as advised in Debian Med policy document. I
guess this was not intentional and should be included in normal cases.
(Again, if policy remains unclear just ask.)
$ grep ^Vcs- debian/control
Vcs-Svn: svn://svn.debian.org/debian-med/trunk/packages/pyhmm/trunk/
Vcs-Browser: http://svn.debian.org/wsvn/debian-med/trunk/packages/pyhmm/trunk/
As I see you just used your first package as template which is a good
idea - however, you seemed to forget to chaqnge the URLs (s/phymm/pscoils/)
[Done]
debian/control: Description-Field
The information you are providing is really sparse. Please keep in mind
that Debian has Millions of users all over the world (at least ;-)) and
the general user should at least be able to make some slight sense of
the description (at minimum detecting that it is not for his own use)
and will not be forced to do some research about its meaning. If you
would have issued an ITP bug report (see above) people would have most
probably told you about this. So please try to be more verbose in the
Description field (short+long description).
$ grep "^#" debian/copyright
# Please also look if there are files or directories which have a
# different copyright/license attached and list them here.
Please delete useless templates (provided that you did followed the advise
but as Upstream yourself this seems to be no issue)
$ cat debian/docs
LICENSE.TXT
Lintian will claim this as "extra license file". Please do not install
this in addition to debian/copyright. Your docs are in doc/ and most
probably you want to look the file debian/docs like this:
doc/*.pdf
As a hint to you with your upstream hat on: please remove everything
except *.tex and *.pdf from your doc/ directory. Its just ugly to have
uncleaned tarballs.
$ grep -A5 "# Sample " debian/rules
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.
You do not honestly want to tell your fellow eam members that this a
sample rules files, right? It is a real rules file to build pscoils and
this this useles dh_make comment should be deleted at least if not
replaced by something which makes more sense like:
# debian/rules for pscoils
# Author: ...
or something like this. These dh_make templates at somepoint will drive
me crazy enough to file bug reports against packages featuring it.
debian/patches/debian-changes-1.0+20120128-1
This file contains changes in the testing code including a modified
test/test.sh. I have no idea what the motivation behind this might be.
As upstream you are in a good position to change the tarball properly to
not need patches at all. Regarding the files test/*.OK I suspect that
these are a result of a test run and should be deleted in the clean
target in debian/rules afterwards. To do so use:
override_dh_clean:
dh_clean
rm -f test/*.OK # or whatever else might make sense
To get rid of ths patch I have [Done] the following:
$ quilt pop -a
$ rm -rf debian/patches
After having inspected all these files I tried (p)debuild which resulted
in a set of lintian warnings. As I said previousely here on your list
lintian is your friend even if it is a very picky friend - it is on your
side. I will only gice comments on those warnings which are not
connected to things I have explained above. If you call lintian with
"-i" option it will give you usually enough hints to solve the issue
on your own.
W: pscoils source: missing-field-in-dep5-copyright paragraph 2 license
W: pscoils source: missing-license-text-in-dep5-copyright paragraph 3 gpl-2.0+
This is connected to an empty line which should not be there. Try to
follow the hint of Charles Plessy given here recently and use
config-edit from libconfig-model-perl (I hope I remember this hint
correctly - can't check while sitting in the plane).
W: pscoils: script-with-language-extension usr/bin/psCoils.py
Here lintian -i gives quite a verbose explanation. Please rename the
script - it might even not harm to do this as upstream.
I have njected the changes I have [Done] into SVN because it is just
back now. Just keep on working there and inject your other packages
as well (some comments coming in my next mail).
Thanks for working on this and it was a pleasure to meet you
Andreas.
--
http://fam-tille.de
Reply to: