Hi Steve, Thanks for taking the initiative. I've been reading the Ubuntu diff every time we've released a new cyrus-sasl2 version. Each time I've wondered about this difference but so far I haven't really given it much thought. Now that you asked, I took the time to meditate a little bit on it. I also agree that there is little reason for the Ubuntu diff to be large. It would be really nice to get feedback from Ubuntu maintainers on all issues regarding this package. You are welcome to approach us on our package mailing list [0] or in the form of bug reports such as this.
[0] pkg-cyrus-sasl2-debian-de...@lists.alioth.debian.org
(non-subscriber posts are moderated)
On Tue, 2009-06-09 at 19:57 -0700, Steve Langasek wrote:
> The libsasl2-2 package states quite explicitly that:
>
> If you intend to use this package on a server that provides SASL
> authentication, then you must install some of the libsasl2-modules*
> packages.
>
> This suggests that the modules should actually be dependencies of the
> package rather than merely recommends, which is what the Ubuntu package
> currently does as a result.
Actually, the sentence does start conditionally. The "must install" part
only applies if these two conditions are met:
1. The user intends to use the package on a server, and
2. the user intends to provide SASL authentication on that server.
So those -modules* packages are not needed for, say, a regular desktop
machine. I think we can safely assume that a significant portion of both
Debian and Ubuntu users don't meet those two conditions. They only have
libsasl2-2 installed because it happens to be a Priority: important
package and it's installed automatically. They are probably not even
aware of it.
Why is libsasl2-2 of important priority? Could we downgrade its
priority? I guess one answer is that for some definition of "experienced
Unix person", it needs to be this way to fulfil the Debian Policy
requirements (2.5). Another answer is that some other Priority:
important packages depend on it, so it needs to be important or all
those other packages need to have their priority downgraded. Finally, as
Russ pointed out, there is a technical reason why libsasl2-2 needs to be
installed, due to the way shared libraries work. So downgrading the
priority doesn't seem like a real option.
libsasl2-2 recommends libsasl2-modules, so the latter is now installed
automatically. This provides a complete and working setup,
using /etc/sasldb2 as the backend for storing authentication
information. The package relationship also allows the user to remove the
-modules package, which can be useful in some situations: embedded or
otherwise constrained systems, or because the user simply has no need to
perform SASL authentication and merely has to have the library installed
to be able to run some other program.
Going further, libsasl2-modules is required by all the other -modules-*
packages. It is needed for them to work, because otherwise there are no
authentication mechanisms to use. There is a difference in function
between the modules in libsasl2-modules and the modules in the other
-modules-* packages. The other -modules-* packages provide ways to store
authentication tokens in something else than /etc/sasldb2, whereas
libsasl2-modules provides different authentication schemes (listed in
the package description).
libsasl2-modules suggests the -modules-* packages individually (the MIT
and Heimdal version of the GSSAPI modules are suggested ORed together
because only one can be installed at a time) because having installed
libsasl2-modules, it is possible to get additional functionality via the
other -modules-* packages. The user can then choose which of those to
install, if any. The user will have to know what the choice means,
because it is essential knowledge required to set up a SASL
authentication system with a more heavyweight storage backend
than /etc/sasldb2 for the authentication information. Each of the
-modules-* packages then pull in whatever additional dependencies they
need -- dependencies that we do not wish to impose on users by default.
I think this is quite logical and allows a user to choose the minimum
set of packages for any particular use case. It also allows users to
start by selecting the -modules-* package which provides the desired
storage backend, and have everything else pulled in through
dependencies. There has never been much confusion over this in the form
of bug reports, questions on the package mailing list, or special
mention in guides and howto's describing SASL setup on Debian. Users
seem to find the packages they need and what is causing them trouble is
configuring SASL-using applications correctly.
I think the problem is a misunderstanding of both the purpose of the
libsasl2-modules package and the difference in function between
libsasl2-modules and the other -modules-* packages. At the very least,
it is a misinterpretation of the package description, possibly because
the description is too complicated or unexpected.
So I would suggest keeping the package relationships as they are. If you
agree, let's close this bug and reduce the Ubuntu diff.
Could we prevent this misunderstanding/misinterpretation from occurring
again? Perhaps someone could suggest better package descriptions? Also,
documentation contributions are more than welcome, because users seem to
have had some difficulty over the years in setting up SASL-using
applications correctly.
Cheers,
--
Fabian Fagerholm <fa...@paniq.net>
signature.asc
Description: This is a digitally signed message part
