On Tue, Jun 09, 2009 at 10:50:39PM -0500, Dan White wrote:
>> 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. Here is a patch that implements this:
>> -Depends: ${shlibs:Depends}, ${misc:Depends}
>> +Depends: ${shlibs:Depends}, libsasl2-modules (= ${Source-Version}) |
>> libsasl2-modules-sql (= ${Source-Version}) | libsasl2-modules-gssapi-heimdal
>> (= ${Source-Version}) | libsasl2-modules-kerberos-heimdal (=
>> ${Source-Version}), ${misc:Depends}
>> Conflicts: postfix (<< 2.3.4-3), libsasl2-gssapi-mit (<< 2.1.22),
>> libsasl2-krb4-mit (<< 2.1.22)
>> -Recommends: libsasl2-modules (= ${binary:Version})
> See: http://qa.debian.org/popcon.php?package=cyrus-sasl2
> Summary:
> libsasl2-2 install base: 98.94%
> libsasl2-modules install base: 54.72%
> libsasl2-modules-sql install base: 1.17%
How does this show anything other than that most users have left the sasl
library in an unusable state on their systems?
> Personally speaking (I'm not a package maintainer), I think these
> dependencies should belong in the packages that use them (such as
> cyrus-imapd). libsasl2-2 itself should keep it's dependencies small.
No, they should not. The whole point of SASL is to abstract away the
authentication methods - server packages should not be depending directly on
particular SASL modules.
> The gssapi and sql packages have a fair amount of 3rd party dependencies
> that many admins probably won't ever need.
This doesn't appear germane to the patch I've proposed, which has an ORed
dependency requiring only that *some* SASL module be installed.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
