Rob,

IIRC, I had replied to Ross on a similar query, start GNOME 2.24. Still
OpenSUSE ships with in-built libdb. I'm not aware of any other distro.

JPR, who use to maintain Evolution few years back, gave me the notes on
why it was decided to go this way (forking libdb). So if we have answers
for all those points, I'm fine for that. We don't want to break anything
thatz fine otherwise. I'm not tracking libdb at all, if you have the
answers, then lets recalculate and plan for it in 2.26.

-Srini.

On Mon, 2008-10-06 at 14:59 +0100, Rob Bradford wrote:
> Since we're at the start of the cycle shall we go ahead and drop the
> included libdb ? and thus add a formal requirement on using the system
> version. AFAIK all the distributors ship with using the system
> version...
> 
> I've updated the bug #410164 with a patch that makes this change.
> 
> Regards,
> 
> Rob
> 
> _______________________________________________
> Evolution-hackers mailing list
> Evolution-hackers@gnome.org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers
--- Begin Message ---
Ross, 

I had a chat with JP and He pointed me to a old README.

===
The issue was around no backwards compatability, from the old README:

 - Berkeley's libdb - 3.1.17

   db3 is available from http://www.sleepycat.com. Make sure to get
   3.1.17, it isn't the latest version.

     --- IMPORTANT WARNING ---

     The on-disk format of DB files has been changing between versions
     2, 3 and 4.  Also, because of the libdb API, there is no way to
     easily handle the different formats from within the application.
     For this reason, Evolution has chosen to use one specific version
     of the library (version 3) and stick to it, so that users do not
     need to convert their addressbook files to use them with
     different version of Evolution.

     That's why Evolution REQUIRES libdb 3.1.17, and NO OTHER VERSION.

     If you force the check to accept a version different from 3.1.17,
     your binary of Evolution will be using a different format from
     the chosen one; this means that it will not be able to read
     addressbook databases created by other versions of Evolution
     which were compiled in the standard way.  Also, we DO NOT
     GUARRANTEE that Evolution will work with different versions of
     libdb at all, even if it can be trivially made to compile against
     them.

     SPECIAL NOTE FOR BINARY PACKAGERS:

     If you are making binary packages for end-users (e.g. if you are
     a distribution vendor), please statically link Evolution to
     Berkeley DB 3.1.17, as mandated by the configure.in check.  DO
     NOT patch configure.in to work around the check.  Forcing the
     check to link to a different version of the library will only
     give headaches and pain to your users, who will see their
     addressbook disappear and will complain to us (the Evolution
     team) about losing their data.

     Besides, libdb will be linked statically, which means that your
     distribution doesn't actually need to ship DB 3.1.17 itself
     separately.

     The Evolution team will be infinitely grateful for your
     co-operation.  Thanks.

This proved quite painful for distros (hanging on to a specific version)
though so we moved it inside e-d-s eventually.  That way we always had a
known quantity.
===

Ross, if we have an answer for this, we can close on this immediately.

-Srini.

On Fri, 2008-04-25 at 08:46 +0530, Srinivasa Ragavan wrote:
> Ross,
> 
> IIRC, it was done because, every libdb update broke Evolution or libdb
> wasn't so stable release over release. Also OpenSUSE uses statically
> linked libdb. But most of the hackers I know, dynamically link libdb.
> I'm favor of the change. But lemme ping some old evolution hackers who
> were part of this change, to understand what they feel about it. 
> 
> -Srini
> On Thu, 2008-04-24 at 14:42 +0100, Ross Burton wrote:
> > Hi,
> > 
> > I think that we should remove the fork of Berkeley DB from the Evolution
> > Data Server source.  Debian, Ubuntu, Gentoo and Fedora all use
> > --with-libdb to dynamically link to a system library, so it is known to
> > work.
> > 
> > This would involve removing libdb from svn, and always dynamically
> > linking to libdb instead.  --with-libdb would still exist for people who
> > want to use a custom libdb, but it would default to /usr.
> > 
> > Thoughts?
> > 
> > Ross
> > _______________________________________________
> > Evolution-hackers mailing list
> > Evolution-hackers@gnome.org
> > http://mail.gnome.org/mailman/listinfo/evolution-hackers
> 
> _______________________________________________
> Evolution-hackers mailing list
> Evolution-hackers@gnome.org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers

--- End Message ---
_______________________________________________
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to