[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 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.
> * 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.
> 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....")
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/*.
But again, this one's your call.
Peter
Attachment:
signature.asc
Description: Digital signature