Re: [DebianGIS] TileCache 2.0 debian packaging
On Mon, Dec 24, 2007 at 01:35:40PM +0930, Paul Wise wrote:
> On Dec 23, 2007 2:28 PM, Christopher Schmidt <crschmidt@metacarta.com> wrote:
> > 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.
I've removed it from debian/copyright.
> > > 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".
Sorry, I had assumed the problem was the inconsistency. At one point, we
had included these lines in all the files, but we had decided that this
wasn't really worth it later down the road.
Is it not safe to assume that files distributed as part of a package,
with a LICENSE.txt in the documentation, are under the license as
described in LICENSE.txt (or debian/copyright)? Does each individual
file need the copyright license?
Does this apply to docs and the like as well?
> 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.
See other post -- but yes, using python-boto is better, since error
messages are actually passed up the chain rather than simply being
barfed on like they probably are currently :)
> > > 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.
If it was trivial to change, that would be one thing, but I literally
removed about half the file, and rewrote another quarter :)
> > > 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.
Okay. Is this a bug in my rules file that I need to fix, or is the way
things are now okay? (I'm not so good at this; sorry if this is a stupid
question.)
> > > 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.
Does an empty "binary-arch:" count as 'succeding'? I assumed not -- I
thik you're saying yes? Also, still confused as to why my lintian didn't
whine on that -- since it's a W, I'd have expected to see it. Weird.
I've removed the 'true', and it still seems to build: going with that.
> > > 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.
Ah, I was ignoring the "I" lines, thinking they were just informational.
Having read
/usr/share/doc/debian-policy/policy.html/ch-relationships.html more
carefully, I agree, and I've moved them.
> Also, the manual page metions flup & python paste, perhaps python-flup
> & python-paste should be in suggests?
Yep, done.
Thanks again!
Regards,
--
Christopher Schmidt
MetaCarta
Reply to: