[There are some questions at the end; comments would be greatly appreciated on the questions if you have ever been involved in the release process or library transitions before. This is my first big transition.] The libkrb53 package (providing the MIT Kerberos shared libraries) has been stable for the last eight years. However, in 2006, MIT announced its plans to remove support for the Kerberos 4 protocol [1]. Kerberos 5 has been the current version of Kerberos since the mid 1990s; increasing security and code quality concerns motivated MIT's decision. In the upcoming 1.7 release of MIT Kerberos, the code will be removed. However, for well over 10 years, MIT Kerberos supports building with the Kerberos 4 code disabled. [1] http://web.mit.edu/kerberos/krb4-end-of-life.html I believe in managing things in small chunks. I'd rather handle removing Kerberos 4 independently of upgrading to a new version of Kerberos (1.7). As such, I plan to turn off Kerberos 4 in Debian unstable in the very near future. Only two packages in Debian actually rely on krb4 support: kstart and zephyr. In the case of kstart, I believe disabling krb4 support will be relatively simple. In the case of zephyr, things are more complicated because most of the zephyr community uses krb4 to authenticate access. The zephyr maintainer is well aware of the krb4 issue and has been working to resolve it. I do not believe keeping krb4 support in Debian for zephyr makes sense, especially since it would definitely be removed on the 1.7 release of krb5. Two additional packages (barnowl and owl) link against libkrb4 but use no symbols from that library. However, things are more complicated. The krb4 and krb5 shared libraries are all in the libkrb53 package. Since libraries will be removed, that package name needs to change. I propose to split out each library into a single package per our current best practice. See the version of the krb5 package in experimental for specific details of the split. I propose to upload a version of krb5 to unstable in about a week that is basically identical to the krb5 in experimental. I will include some debconf fixes, a news file, and other minor changes. See the experimental branch of [2] for ongoing work towards this upload. [2] git://git.debian.org/git/pkg-k5-afs/debian-krb5.git Unfortunately, there are a lot of packages that reverse depend on libkrb53. All of these packages will need to be rebuilt. Here's where I need sanity checking. I assume that after the new krb5 has made its way into unstable and has built on all arches, I should send mail to all these packages asking them to upload a new version built against the new krb5. I assume that some time (1 week?) later, I should do a mass bug filing against anything that is still uninstallable in unstable because of a libkrb53 dependency. I assume that doing NMUs to fix these bugs would be appropriate. Do I have things right so far? When I file bugs, do I advise people to upgrade their build dependencies to the version of krb5 that introduces the new library packages? Clearly the packages need to be built against that version for unstable. However it seems like that build dependency would make things like backports harder. Would it be better to have an explicit build dependency or just make sure that things are rebuilt after krb5 is built on all arches? Also, note that the ABI of the libraries that will remain is *not* changing. (In a somewhat related note, the soname of libraries that remain will not need to change for 1.7; we won't expect any transition beyond the krb5 package at that point). So, packages not using the krb4 libraries would actually work fine against the libkrb53 in testing. It seems like if I use an alternative dependency in the symbols files for the new package, I could allow packages rebuilt for unstable to migrate into testing ahead of the new version of krb5. That is, if I made the dependency in libkrb5-3.symbols look like libkrb5-3|libkrb53 (and similar changes for other symbols files), then both the packages in unstable and testing would satisfy the dependencies. It seems like this would significantly reduce the impact of the transition. Am I missing something or would this change be a good idea? Attached is a list of the packages that appear to reverse-depend on libkrb53. Thanks for your consideration and review, --Sam alpine aolserver4-nsimap asterisk-bristuff asterisk-classic audispd-plugins auditd autofs5-ldap balsa barnowl bind9 bind9-host bind9utils bitstormlite boinc-client boinc-manager centericq centericq-fribidi centericq-utf8 cgi-mapserver crossfire-client crossfire-client-gtk crossfire-client-gtk2 crossfire-client-x11 cups cups-driver-gutenprint cupsddk cupsddk-drivers curl cvsnt diatheke dnsutils dovecot-common epdfview etpan-ng evolution-data-server fetchmail flickcurl-utils freeradius-krb5 ghostscript gmyth-utils gnustep-gui-runtime gpredict gtklp gtorrent-viewer heirloom-mailx iceape-browser iceweasel inn2 ipopd ipsec-tools jabberd2 jp2a kdelibs4c2a kdelibs5 krb5-auth-dialog kredentials kstart libapache-mod-php4 libapache-mod-php5 libapache2-mod-auth-kerb libapache2-mod-php4 libapache2-mod-php5 libapache2-mod-php5filter libapache2-webauth libauthen-krb5-perl libauthen-krb5-simple-perl libc-client2002edebian libc-client2007b libcamel1.2-10 libcamel1.2-11 libcamel1.2-8 libclamav2 libcups2 libcurl3 libcurl3-gnutls libdns43 libdns45 libexchange-storage1.2-1 libexchange-storage1.2-3 libflickcurl0 libgnomecups1.0-1 libgnomeprint2.2-0 libgnomevfs2-extra libgs8 libgsasl7 libgssapi-perl libgtk2.0-0 libkrb5-ruby1.8 libkrb5-ruby1.9 liblua5.1-curl0 libmail-cclient-perl libneon27 libneon27-gnutls libnet-cups-perl libnss-ldap libnss-ldapd libpam-afs-session libpam-krb5 libpam-pkcs11 libpam-smbpass libpq4 libpq5 libremctl1 libroot5.18 libsasl2-modules-gssapi-mit libsmbclient libsword6 libtinymail-camel-1.0-0 libtunepimp5 libwebauth1 libwfut-0.2-1 libzephyr3-krb lprng lwresd mailsync mailutils mailutils-imap4d mailutils-mh mailutils-pop3d mapserver-bin mpop msmtp mutt mutt-patched nepenthes netatalk netsurf nfs-common nfs-kernel-server openafs-krb5 openssh-client openssh-server owl perl-mapscript php4-cgi php4-cli php4-curl php4-imap php4-mapscript php5-cgi php5-cli php5-curl php5-imap php5-mapscript pike7.6-core postgresql-7.4 postgresql-8.1 postgresql-8.3 postgresql-client-7.4 postman python-kerberos python-mapscript python-pycurl python-pycurl-dbg python-remctl python-samba racoon remctl-server root-plugin-krb5 root-system-proofd root-system-rootd root-system-xrootd rpm rsyslog-gssapi samba samba-common samba-tools sasl2-bin smbclient smbfs squid swat tla tshark uw-imapd uw-mailutils wfut winbind wireshark wireshark-common xfprint4 xpp zephyr-server-krb
Attachment:
pgp_IhaBMLCkf.pgp
Description: PGP signature