On Fri, 15 Sep 2006, Steve Langasek wrote: > > Not to mention that all databases used by sasl need to be db43_upgrade'd > > automatically and safely (backups, and a roolback path), and that cyrus-sasl > > is linked to glibc nssswitch modules, like e.g. openldap, and will segfault > > **EVERY** program in the system if something goes wrong. > > I don't see any way that nsswitch is relevant here. There's no sasl nss > module, and there are no nss modules that link to libdb4.2 -- so if this was
Well, I don't know what openldap is doing lately... yes, libdb should *not* cause problems anymore in debian since we supposedly strongly versioned all of them, but this deserves a test anyway. > I agree that care needs to be taken for database upgrades. Are there fixed > locations for the databases that cyrus-sasl will use, that can be handled in > the maintainer script? Or is this infinitely configurable, in which case > the user will have to do a by-hand upgrade anyway? AFAIK, the location is fixed. /etc/sasldb2. I don't recall if this can be easily overriden on an app-basis, but if it can, there is nothing short of modifying libsasl itself to detect and call db->upgrade() that would fix the issue. And I am *not* advocating that we do that. > > Do *not* change libsasl's default berkeley DB without deploying and testing > > all of the above first. And when you do, upload to *experimental* first, > > please. > > I see no value in an upload to experimental. Experimental doesn't get > enough user testing to be useful for much beyond coordinated rebuilds tests. You can at least *ask* for such tests after you upload to experimental... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
