Simon Josefsson <[EMAIL PROTECTED]> writes: > I renamed the upstream release to shishi_0.0.23.orig.tar.gz and placed > it in ../. That seem to have done the trick, thanks!
> (Couldn't it have used shishi-0.0.23.tar.gz? I'm not sure if I > understand the significance of my step.) The packaging tools require that the upstream source have a very specific name, namely <source-package>_<version>.orig.tar.gz where <version> is the package version without the Debian revision (the bit after the last -). > I now have lintian-clean packages for Shishi! I'm using cdbs, with no > upstream patches, so the diff is quite minimal. All the generated files > are available from: > http://josefsson.org/shishi/debian/ > Any review would be appreciated. Sponsors too, of course... Now that I've finally gotten a new version of OpenAFS uploaded (now with man pages!) I found some time to take a detailed look at this. I noticed the following problems. First, the point that you're really not going to like: * The shishi manual is covered under the GNU Free Documentation License, which is not a DFSG-free license. The shishi-doc package therefore must go into non-free rather than main, unless I can convince you, as upstream, to change the license or dual-license it under a DFSG-free license such as the GPL. Furthermore, since the manual is not DFSG-free, the original upstream source must be repackaged to remove it and anything else that isn't DFSG-free from the .orig.tar.gz file. This is because everything in Debian main, including everything contained in the upstream source tarball even if it doesn't make it into a Debian package, must be DFSG-free. The manual would have to be a separate source package. The DSFG-freeness of the GFDL has been much-debated, but at this point my personal feeling is that the project has reached a consensus that it is not free. All of the packages that contain GFDL documentation already have RC bugs filed against them and this issue will have to be dealt with before the etch release, one way or the other. I, at least, am not willing to introduce more packages with this problem into etch at this point, even if some Debian developers don't agree. For a summary of the problems with the GFDL, see: <http://people.debian.org/~srivasta/Position_Statement.html> The ideal solution to this overall problem is obviously for Debian and the FSF to reach some mutually agreeable license and to relicense all software currently licensed under the GFDL under that license instead. So far, RMS has not indicated much willingness to do this; however, at this point, I'm fairly certain Debian is not going to change our collective mind just because RMS doesn't agree. The ideal solution to the immediate problem would be for you, as the GNU Shishi maintainer, to relicense the manual under a DFSG-free license, at least as an option. This is a painful issue for me personally, as I'm also a FSF associate member and am generally a supporter of the FSF. However, on this particular issue, I believe that the FSF is wrong -- not egregiously, but still wrong -- and is not supporting free software with this license. It may be that you'll find another Debian developer who is more willing to fight the project consensus over this, but I somewhat doubt it. We've already had a pretty extensive discussion internal to the project. Anyway, here are the other issues: * Unless the intention is to have multiple development environments for the library packages installed at the same time (in other words, both a libshishi0-dev and a libshishi1-dev, with both co-existing peacefully), most (myself included) recommend not including the SONAME version in the -dev package. It makes life much easier for Debian release management in general. If you version the dev package and other packages in Debian depend on the library, then when libshishi1 comes along, all of those packages will require updates to their Build-Depends and new uploads. If, on the other hand, the dev package is still just called libshishi-dev, those packages only need binary rebuilds, which can be handled automatically by the Debian release managers. My recommendation would therefore be to build libshishi-dev and libshisa-dev, without the versioning. (The library package names are fine.) * Your shared library packages also contain configuration files and locale data. This is strongly discouraged (Policy 8.2, although the issue applies to more than just run-time support programs) because it means that a user cannot have both libshishi0 and libshishi1 installed at the same time. This makes upgrades during library SONAME changes really painful. The recommendation in Policy is to create a separate libshishi-runtime package (or something similar; various packages have used different names, such as readline-common) to hold these files. In your case, that package can be Architecture: all. The /etc/shisa.conf file is a curious problem, since you really don't want to create a separate package only for a single configuration file. My recommendation would be to create a shishi-runtime package containing all the configuration files and the locale database and have both libshishi0 and libshisa0 depend on it, even though this may mean that a user could have some config files installed they're not really using. * The shishi long package description is incorrect in the last paragraph. It has the package description for the shishi-doc package instead. * You don't need debian/dirs; dh_install will take care of creating the directories for you. * The admin client, shisa, probably should be in the shishi package, not the shishid package, presuming that it works over the network. You don't want to have to install the shishid daemon (particularly since it starts by default) on every system from which you want to manage a KDC. Then you can change the Suggests of shishid to a Suggests of shishi in libshisa0. * The -dev packages go into section libdevel, not devel. devel is for development tools like compilers, revision control systems, and the like. * Given that this is alpha software, the third implementation of Kerberos in Debian, and not necessarily recommended for production use yet, it should be priority extra rather than priority optional. This can always be changed later when it's had a 1.0 release and other packages start depending on it. (The -dev packages should always be priority extra, though.) -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
