Re: [DebianGIS] TileCache 2.0 debian packaging
On Sun, Dec 23, 2007 at 01:13:33PM +0930, Paul Wise wrote:
> On Dec 23, 2007 12:23 PM, Christopher Schmidt <crschmidt@metacarta.com> wrote:
>
> > Approximately 8 months ago, Paul Wise offered a great review of the
> > TileCache Debian packaging materials with an eye towards inclusion in
> > Debian.
> >
> > http://lists.alioth.debian.org/pipermail/pkg-grass-general/2007-April/002565.html
> >
> > Since then, TileCache has been released another 6 times, but no serious
> > effort had been made on improving packaging until today.
> >
> > http://svn.tilecache.org/trunk/tilecache/ has the updated code with the
> > changes I mention below implemented.
>
> A review of the current SVN:
>
> May as well drop the make clean from debian/rules since it isn't used.
I'm assuming this is the $(MAKE) clean, and not the entire clean
section? Which I think is used to do minor cleanup.
> The two latest debian/changelog entries miss blank lines in the right places.
>
> The debian/changelog is meant only for packaging related changes.
Hm, okay. So should I pull all the stuff out of there other than
something like a 'new upstream' for each version? (Done that.)
> No need to build-dep on sed, that should be present on all systems.
Got it. Done.
> Homepage is now a real field: http://wiki.debian.org/HomepageFieldHOWTO
Okay, fixed.
> > > * copyright: move "Copyright (c) 2006-2007 MetaCarta, Inc." into the
> > > copyright holder section
> > Done, I think?
>
> Well, you copied it rather than moved it, so I don't think that this
> is fixed. License != Copyright, the licence goes in the licence
> section and the copyright in the copyright section :)
Okay -- this is another "I'm copying the BSD Template", and I guess I
shouldn't be? (I'm now not.)
> TileCache/Services/*, TileCache/Caches/*, TileCache/Layers/* don't
> seem to have the copyright lines.
None of them should.
> TileCache/Caches/S3.py is copyright by Amazon and has a different
> licence, you should mention that separately in debian/copyright and
> maybe in the upstream docs too
Yep. I just added that this afternoon after most of the packaging
changes and didn't get back to it before sending this email :)
> I also think that you should instead depend on python-boto and use the
> S3 support from that maybe.
The code there is Very Different: the S3.py is a much more minimal "API"
esigned for introspection by someone starting with the code, while boto
seems to be more of a library, on my reading. It's possible that I
should rip out just the bits I need, but I wanted to keep it as close to
upstream as possible. I considered making people grab S3.py manually,
but that seemd a big pain in the butt (There's no direct link just to
the file, and no installation/packaging materials), so I went with just
including it as is.
> If you don't want to do that and the S3.py
> code is also in python-boto, please make sure you notify the security
> team about the code duplication.
It's not: anything special to do in that case?
Actually, thinking about it, I could change the debian package to not
include this code, and only include documentation on how to install it.
I'm fine with that for the debian packaged version: wold this be
preferred?
> Is there any reason that upstream and Debian shouldn't both use
> /usr/sbin or /usr/bin - making Debian different to other distros
> wouldn't really be good.
Well, I don't know what debian wants. I personally think that the
scripts belong where the Python installation tools put them :) But the
FHS says that they belong in /usr/sbin because they are "non-essential
binaries used exclusively by the system administrator." I do think that
this is an accurate description: tilecache_http_server is, for example,
a webserver, so it fits into the same category as apache in that regard,
which is obviously in /usr/sbin.
setup.py will put them in /usr/bin. If it's better to maintain
consistency across platforms, then this should be where they go. If it's
better to maintain consistency with the FHS, then they should likely go
in /usr/sbin.
> Likewise for the manpages - I assume users of BSD and other GNU/Linux
> distros would also appreciate manual pages.
I assume that users of BSD and other distros will need something
different to turn the documentation into manpages. The current (manual)
manpages are entirely debian specific, but the non-debian specific
content is in README.txt, which other distros will have to pick up and
'do the right thing' with.
> > > * CHANGELOG: seems like the kinda thing that should be called NEWS
> > > instead, may want to generate a ChangeLog with svn2cl
> >
> > A commit by commit changelog seems unneccesary to me. "CHANGELOG" seems
> > to be what Debian calls its 'overall list of things changed between
> > releases' file -- why is this different?
>
> I read the GNU standards before I joined Debian - there the summary of
> changes between releases is in NEWS and the log of individual changes
> is in ChangeLog.
>
> This convention is by no means adopted by free software as a whole, or
> even remotely consistent, except perhaps among GNU software and
> software influenced by GNU and automake/autoconf.
Okay. If NEWS is a better name, that's fine with me.
> Also docs/CHANGELOG.txt is missing the 2.0 version.
Hm, something broke then -- I know it got updated at some point. Thanks
for noticing.
I've changed CHANGELOG.txt to NEWS.txt, and changed the
dh_installchangelogs line. I've changed the debian/changelog to just
have minimal "new release" lines.
> I notice that during the build process (in a cowbuilder chroot), it
> downloads and installs a setuptools egg. Doing anything that requires
> network access during the build process is a big no-no.
Ah, that's just a bug in the control file -- python-setuptools should be
a build-depend, which would prevent the download. Added.
> Is it appropriate to run the tests during the build process or do they
> require network access?
They don't require network access -- but I'm not sure where they should
go in the build process. I've added them to build-stamp (when I had them
in build, they ran twice, don't know where the bug is in that).
> lintian errors/warnings/info:
Hm. Your lintian complains about things mine doesn't. And 3.7.3 isn't in
my debian-policy changes... Ah, I assume this is an etch vs. not-etch
thing. Yes, it is. Okay, I've upgraded to 3.7.3 and confirmed that I
wasn't affected by anything in the upgrading-checklist.
> E: tilecache source: debian-rules-missing-required-target binary-arch
Fixed with:
binary-arch:
true
Which is based on: "Both the binary-arch and binary-indep targets must
exist. If one of them has nothing to do (which will always be the case
if the source generates only a single binary package, whether
architecture-dependent or not), it must still exist and must always
succeed." from section 4.9.
> W: tilecache source: out-of-date-standards-version 3.7.2 (current is 3.7.3)
Fixed.
> E: tilecache source:
> build-depends-on-essential-package-without-using-version
> build-depends: sed
Fixed.
> I: tilecache source: build-depends-without-arch-dep python
> I: tilecache source: build-depends-without-arch-dep python-support
> I: tilecache source: build-depends-without-arch-dep sed
> W: tilecache: description-contains-homepage
Fixed.
My lintian report now says:
crschmidt@bia:~$ lintian tilecache_2.0_all.deb
crschmidt@bia:~$
Thanks again for the fast feedback!
Regards,
--
Christopher Schmidt
MetaCarta
Reply to: