9:19 a.m.
Hi again,
this is my review of the configshell-fb packaging.
debian/source/format
Should be 3.0 (quilt), not 3.0 (native). See [1] for details about
the distinction.
debian/copyright
I very much prefer DEP-5 style copyright files. I did some git
archeology and some analysis of the license grants in the code, and I
came up with the following:
https://github.com/chris-se/configshell-fb/blob/053e12e9364dc147668f77d80...
A detailed description of the format can be found under [2]. I've
added Ritesh and myself there for now, under the assumption that
we'll co-maintain this in Debian.
debian/rules
It works, but is _way_ too complicated. There is something called
pybuild in Debian [3], which does all the magic for different Python
versions automatically. And normally Python packages would work
automatically with that when using the dh(1) wrapper. The problem is
though that in your case there's a Makefile in the root directory, so
debhelper will assume a Makefile-based build system.
However, you can force debhelper to use pybuild and not try to auto
detect the build system by specifying -S in the dh line:
dh $@ --with python3,python2 -Spybuild
This will also take care of the proxy settings (to disable network
access) and all these things, simplifying debian/rules significantly:
https://github.com/chris-se/configshell-fb/blob/41d0149313cdf13441542807b...
This also has the advantage that changes to how Python packages are
managed in Debian are more likely to work just out of the box via
debhelper, instead of having to manually implement them oneself.
debian/control:
In Debian proper (though not upstream) there should be an Uploaders
field if the Maintainer: field is a mailing list. The natural
candidates for that field would be you (Christophe), Ritesh and
myself.
Also, a moderated list is a really bad idea for Maintainer: when the
pacakge is uploaded to Debian, because lots of automated mails go
there. Unfortunately, since Ritesh had been maintaining the LIO
stack himself in Debian so far, there's no mailing list for the
Alioth project available right now. For the initial upload to Debian
we could probably just move one of the Uploaders: to Maintainer:, and
organize a packaging mailing list later.
The Build-Depends/Build-Depends-Indep split is useless, since the
package only generates Architecture: all packages. Therefore I'd
suggest to simply put everything in Build-Depends.
When testing package build in a clean chroot, pyparsing was missing
as a build dependency.
The -doc package doesn't have Depends: ${misc:Depends}, even though
all packages should have that if debhelper is used. (Even though it
will not actually add anything there currently, that might change at
some point in the future.)
debian/changelog
Obviously that'll have to be updated (and an ITP be filed) before
this can be uploaded to Debian.
I've fixed all these things (except the Maintainer: field) in a fork
of your packaging branch on my github:
https://github.com/chris-se/configshell-fb/commits/debian-packaging
Regards,
Christian
[1]
https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a...
[2] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
[3] https://wiki.debian.org/Python/Pybuild