Re: [DebianGIS] TileCache 2.0 debian packaging
On Dec 23, 2007 2:28 PM, Christopher Schmidt <crschmidt@metacarta.com> wrote:
> > 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.
Yeah.
> > 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.)
Yep. Usually we use uupdate, which puts "New upstream release" in the changelog.
> > > > * 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.)
Cool. Still not sure if "all rights reserved" is appropriate. I seem
to remember reading on debian-legal that it is obsolete because of the
current state of copyright laws. Minor issue anyway.
> > TileCache/Services/*, TileCache/Caches/*, TileCache/Layers/* don't
> > seem to have the copyright lines.
>
> None of them should.
Who wrote them? Are they BSD licenced? Giving explicit permissions is
unfortunately one of the requirements of current copyright laws, which
are mostly "copyright by default, all rights reserved, do not touch".
> > 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?
Since there is no code duplication, I don't think it is nessecary to
remove S3.py and if it isn't removed then you should only suggest
python-boto if using it rather than S3.py brings some advantages that
S3.py doesn't have - new features, less bugs or whatnot.
> > 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.
Hmm, I tried to find a way to get setuptools to use sbin, couldn't
work it out. I guess having Debian different is fine.
> > 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.
Hmm, ok. The usual way to deal with system-specific differences is to
have ./configure (./setup.py in this case) generate the manual pages
at build time. Anyway, not a huge issue.
> > 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).
The bug with adding them to build would be that make always runs
.PHONY targets and both the install and binary-indep targets depend on
build.
> > lintian errors/warnings/info:
>
> Hm. Your lintian complains about things mine doesn't.
I use the sid version and also the -I argument to show up things that
are potentially a problem but are not shown by default because they
may be false positives.
> > 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.
That seems to have added this warning:
W: tilecache source: binary-arch-rules-but-pkg-is-arch-indep
N:
N: It looks like you try to run code in the binary-arch target of
N: debian/rules, even though your package is architecture- independent.
N:
Removing the true line seems to fix this.
> > I: tilecache source: build-depends-without-arch-dep python
> > I: tilecache source: build-depends-without-arch-dep python-support
> Fixed.
I still see these, and also this one:
I: tilecache source: build-depends-without-arch-dep python-setuptools
I think that these build-depends belong in Build-Depends-Indep.
Also, the manual page metions flup & python paste, perhaps python-flup
& python-paste should be in suggests?
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: