Re: about to remove libdb4.1
* Ondrej Sury | I think that this could be delicate issue, because evolution creates DB | files in .evolution and it has to be migrated automaticaly for an user. | So bug is OK, but NMU would not be AFAIK welcomed, since it could broke | user addressbooks, etc. | | Takuo, am I right? FWIW, this is just about the same response I got from upstream when I asked them about the issue. The solution is of course to get rid of libdb and use tdb or something equivalent. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: about to remove libdb4.1
FWIW, this is just about the same response I got from upstream when I asked them about the issue. The solution is of course to get rid of libdb and use tdb or something equivalent. Maybe you should convince bogofilter upstream to keep supporting tdb. They're dropping it on the grounds that it's slow and useless. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: about to remove libdb4.1
* Ondrej Sury: I think that this could be delicate issue, because evolution creates DB files in .evolution and it has to be migrated automaticaly for an user. Which Berkeley DB feature set is needed by evolution? The database format itself has not changed since 4.0, so no migration would be necessary unless specific Berkeley DB features are used (like the transactional data store). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
about to remove libdb4.1
Hi, libdb4.1 should be removed from Debian soon. The following packages still use it (but could move forward to the more recent db4.2 or db4.3 package): arla kerberos4kth-servers vacation libedataserver1.2-4 libroken16-kerberos4kth kerberos4kth-kdc libapache-mod-witch libotp0-kerberos4kth evolution-exchange evolution-data-server1.2 xsim evolution libapache-mod-aspseek evolution-data-server libapache-csacek libapache-mod-speedycgi libdb4.1-ruby1.6 squidguard libedataserver1.2-dev libapache-mod-auth-shadow pkspxyc libdb4.1-ruby1.8 I itend to file important bugs on all of these packages, and after a while, start to NMU these packages. Is there a problem with that? As libdb4.1 is currently RC-buggy, and nobody really intends to put time into the fix, we need to go forward a bit faster than usual. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: about to remove libdb4.1
On Sun, 2005-07-31 at 15:32 +0200, Andreas Barth wrote: Hi, libdb4.1 should be removed from Debian soon. The following packages still use it (but could move forward to the more recent db4.2 or db4.3 package): libedataserver1.2-4 evolution-exchange evolution-data-server1.2 evolution evolution-data-server libedataserver1.2-dev Hi, I think that this could be delicate issue, because evolution creates DB files in .evolution and it has to be migrated automaticaly for an user. So bug is OK, but NMU would not be AFAIK welcomed, since it could broke user addressbooks, etc. Takuo, am I right? Ondrej. -- Ondrej Sury [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: about to remove libdb4.1
2005-07-31 (日) の 22:34 +0200 に Ondrej Sury さんは書きました: On Sun, 2005-07-31 at 15:32 +0200, Andreas Barth wrote: Hi, libdb4.1 should be removed from Debian soon. The following packages still use it (but could move forward to the more recent db4.2 or db4.3 package): libedataserver1.2-4 evolution-exchange evolution-data-server1.2 evolution evolution-data-server libedataserver1.2-dev Hi, I think that this could be delicate issue, because evolution creates DB files in .evolution and it has to be migrated automaticaly for an user. So bug is OK, but NMU would not be AFAIK welcomed, since it could broke user addressbooks, etc. Takuo, am I right? Yes. I think so too. -- Takuo KITAME -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
