Re: Interest in packaging GNU Shishi and GNU Generic Security Service?
Russ Allbery <rra@debian.org> writes:
>> 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.
Thank you for the review!
> 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.
I'll bring this up on the FSF developers list, to see if anyone has
suggestions. I think having a secondary optional license would be
acceptable.
As for the license, I think GPL amended with a GFDL escape route would
work. I.e., it is also redistributed under a license that is GPL but
gives users the right to use the manual under GFDL too. This isn't
exactly the same as dual-licensing, since I want people to be able to
always use it under GFDL, which wouldn't be possible if someone took
the manual and made GPL-only changes to it.
> 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.)
Sounds good, I have changed this. It is also my intention that the
API should be fairly stable, but it is too early to make any promises
about that. The library uses versioned symbols, at least.
> * 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.
Done, although I called it shishi-common.
(As an excuse, I based this decision on another of my packages, GNU
SASL, its Debian package libgsasl7 also contain the locale data.)
> * The shishi long package description is incorrect in the last paragraph.
> It has the package description for the shishi-doc package instead.
Fixed.
> * You don't need debian/dirs; dh_install will take care of creating the
> directories for you.
Removed.
> * 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 admin doesn't work over the network currently, although it has a
plugin design that likely will lead to some backend plugin accessing
the network in the future. The most realistic plugin would be LDAP.
I created a separate package for the admin tool instead.
This issue runs into one of the goals of Shishi, which I admit is not
clearly documented: the intention is to run a daemon on every machine,
so that every machine is a Kerberos realm, and then use Kerberos
cross-realm trust to build up larger networks. This work isn't
completed yet, and I don't think it affect the Debian packages yet,
but may be useful to know in the future. The intention is that
Kerberos should simply work without any manual configuration, and that
adding cross-realm trust between two hosts should be a simple process.
There is a PAM module for Shishi that is needed for that, but I
haven't packaged it yet. Just having the library and client available
in Debian is sufficient for now, I can think about how to integrate
the other issues later.
> * The -dev packages go into section libdevel, not devel. devel is for
> development tools like compilers, revision control systems, and the
> like.
I see, thanks!
> * 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.)
I don't really understand the difference, but I have changed this.
Thanks,
Simon
Reply to: