[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#326429: ITP: webcheck -- website link and structure checker

[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.


Attachment: signature.asc
Description: Digital signature

Reply to: