[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
signature.asc
Description: Digital signature