Re: Interest in packaging GNU Shishi and GNU Generic Security Service?
Simon Josefsson <jas@extundo.com> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: