Question about removal of cyrus-sasl2-mit

[Russ Allbery]

Roberto C Sanchez <roberto at connexer.com> writes:
> On Mon, Dec 11, 2006 at 10:49:50AM -0800, Russ Allbery wrote:

>> Wait, woah.  You shouldn't just remove libsasl2-gssapi-mit from etch
>> without a transition package so that people who are upgrading from
>> sarge still have the MIT GSSAPI SASL module installed.  That would
>> break a bunch of our servers.
>> 
>> I agree with the removal since the base SASL libraries are now newer
>> and the old modules may well not work, but we should provide a better
>> upgrade path than just having the package disappear.

> Please read my original message.  The new cyrus-sasl2 packages are
> linked against MIT Kerberos.

I did, and I understand that.  You're not understanding the problem, I
think.

> In fact, the new libsasl2-modules-gssapi-mit package replaces and
> conflicts with the one produced by cyrus-sasl2-mit.  Thus, the upgrade
> path has already been planned and implemented.

No, that still doesn't provide an upgrade path.  That means that the right
thing will happen if someone manually installs
libsasl2-modules-gssapi-mit, which isn't the same thing.

If I have a system that has:

    libsasl2
    libsasl2-gssapi-mit

installed and I do an upgrade, I'm going to end up with a system that has
the new libsasl2 and continues to have libsasl2-gssapi-mit installed on
it.  There's no conflict in libsasl2-2 that would remove
libsasl2-gssapi-mit and libsasl2-gssapi-mit only requires libsasl 2.1.19
or later.  That system is going to end up with an old, broken module
installed that will probably fail to work.

If make libsasl2-2 conflict with libsasl2-gssapi-mit, then the latter
package will get removed, so at least the system isn't broken.  However,
nothing is then going to go find libsasl2-modules-gssapi-mit and install
it.  That's not how Conflicts and Replaces works; apt isn't smart enough,
when seeing a conflict that can be resolved by just removing a package, to
instead go seek out a package that replaces it.

You need to provide a transitional package named libsasl2-gssapi-mit that
depends on libsasl2-modules-gssapi-mit and version the Conflicts and
Replaces on libsasl2-modules-gssapi-mit.  You probably also want to make
libsasl2-2 conflict with the old libsasl2-gssapi-mit.  Otherwise, so far
as I can tell, people who have the current MIT GSSAPI modules installed
will not get the new modules after a sarge to etch upgrade.

That transitional package can then be removed for lenny.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>