On Wed, 2005-09-07 at 00:47 -0500, Peter Samuelson wrote:
> [Arthur de Jong]
> > I'm not sure if I need some statement on the copyrights on the
> > generated html files. The css file that is just copied has a BSD
> > license.
>
> Generally, output from a program is not considered to be copyrighted.
> The templates from which it is built could be copyrighted, and if
> significant bits of a template are copied in verbatim, you may wish to
> copy in a license statement from the template too.
The templates are embedded in the python code (e.g. write('<html
code>')) (except for the mentioned css file). The python code is GPL.
Most of the content (links, titles, other gathered information) is from
the crawled website.
> > The old package provides, conflicts with and replaces linbot (the
> > name of webcheck a long time ago). Should I keep that or just drop
> > it? (linbot was in slink, potato and woody but neither linbot or
> > webcheck were in sarge)
>
> Completely your call. You do not need to support upgrades from woody
> or prior, but you can if you wish. Three lines in debian/control
> which you'll never need to change is a pretty cheap price, but it *is*
> untidy if you want a minimalist control file.
I think I'll keep those lines for a while then (they're not in the way
for now).
> > The old package has a configuration file in /etc/webcheck and the
> > new package no longer provides that. What would be the best way to
> > get rid of it? (policy 10.7.3 has a note about removing conffiles
> > but I'm not sure it's relevant) Should I delete it on upgrade?
>
> Is the package configured in some other way, or have you dropped
> support for any site-wide configuration? If you still have a
> configuration mechanism, it's best if you can migrate /etc/webcheck to
> the new scheme automatically, then delete it, at upgrade time. If
> not, you can just delete it.
The new package does not use a configuration file at all any more (the
config.php file is still there but it is not really meant to be edited
any more and is not in /etc). I don't think I want to keep a site-wide
configfile. Maybe I'll support specifying a configfile from the
command-line one day.
I'm going for completely removing the /etc/webcheck directory on
upgrades. Anyone think there should be a debconf question about this at
install time (e.g. test if /etc/webcheck exists and ask the user to
remove it)?
> > Btw, I'm packaging this as a native Debian package because I just
> > want to release one version and have one source tarball.
>
> Not recommended - you'll have to release a whole new "upstream
> version" any time you fix a trivial Debian bug, or even just to
> recompile against a newer sid library. Providing backports or forks
> (for etch after etch is frozen) will require new upstream version
> numbers, which will confuse your non-Debian audience ("wait, what's
> the current release? Upstream 3.1.15 and 3.1.15~etch1 were released
> at the same time, but 3.0.4.etch2 was just added to the debian ftp
> site....")
I think this would avoid confusion since every Debian version is also a
released version. If a release changes just Debian packaging (unlikely
at the moment since it is in development) that will be documented in the
NEWS file. Since this is a python package with architecture: all the
risk of recompiles are minimal. I'm not too worried about the version
numbers of backports or forks because priority is extra (not likely to
be affected by major freeze problems) but adding a .etch# or .sarge#
suffix shouldn't cause too much confusion.
> And there's the bandwidth issue - you and the build daemons have to
> transfer the whole source tarball every time you make a trivial change
> to debian/*.
The current tarball is pretty small (45k plus maybe 5k for a debian
directory) and since the architecture is all (no buildds) I don't think
we'll be having a lot of bandwidth issues.
Thanks for you comments!
--
-- arthur - adejong@debian.org - http://people.debian.org/~adejong --
Attachment:
signature.asc
Description: This is a digitally signed message part