>>>>> "Andreas" == Andreas Barth <a...@not.so.argh.org> writes:
Andreas> About the bug itself: How about e.g. adding an transition
Andreas> package libkrb53 to unstable which depends on libk5crypto
Andreas> and also libk5crypto breaks the lenny libkrb53. That
Andreas> together would makes sure that the breakage doesn't happen?
Andreas> That transition package can then be dropped after one
Andreas> release cycle. (Please just say if that's a silly idea.)
Andreas> The same is true for all other split off packages of
Andreas> course.
So, the reason we're splitting out libkrb53 is that upstream dropped
some APIs and ABIs in krb5 1.7. In particular, the libkrb4.so.2 ABI and
the libdes425.so.something ABI are dropped. Those ABIs were all part of
libkrb53 from about 2000 when I first packaged krb5 until
squeeze/karmic.
For krb5 1.7 it would have been relatively easy to make a transition
package using code from krb5 1.6 that provided the removed ABIs.
However upstream has this annoying tendency to improve their code and
has significantly reorganized a bunch of internal APIs for better
modularity and performance. As a result, the implementations of
libkrb4.so.2 and libdes425 in krb5 1.6 depend on chunks of code simply
not present in krb5 1.8. I have not investigated making a transition
package but I suspect that making a package that preserved the ABI would
be more effort than I can dedicate.
There are only two packages in lenny that use these ABIs: zephyr and
kstart (besides krb5 packages themselves). However there are also
probably lots of user applications linked against theses libraries.
So, here are some options:
1) generate stub functions that return errors and produce a transition
package. Doing that for libkrb4.so.2 is probably easy because of work
done for the Mac. Doing that for libdes425 is probably more time than I
have, although especially with help is dobale.
2) Produce a transition package that actually drops the libraries. That
would mean some programs in lenny would segfault if you installed that
package. We could add conflicts. However we'd create segfaults for
non-packaged applications linked against libkrb4.so.2 or libdes425
3) Create a prerm script in the new libraries that prevents there
removal if libkrb53 is installed. We'd need to make sure that the
downgrade procedure described in the news file (or some variation) could
still be executed. That's a solution to this bug but not to #566988.
I'd still really appreciate input on how this situation comes up for
real users. The cases where libk5crypto3 gets installed without a bunch
of dependencies to keep it in place still seem very rare to me.
--Sam
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
