Re: [Evolution-hackers] Getting rid of shipped libdb
On OpenSolaris, libbdb is not shipped so Evolution still uses the private copy of BDB. Jeff On Mon, 2008-10-06 at 22:15 +0530, Srinivasa Ragavan wrote: > 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 > email message attachment, "Attached message - Re: [Evolution-hackers] > Removing libdb from EDS source" > > Forwarded Message > > From: Srinivasa Ragavan <[EMAIL PROTECTED]> > > To: Ross Burton <[EMAIL PROTECTED]> > > Cc: Evolution Hackers > > Subject: Re: [Evolution-hackers] Removing libdb from EDS source > > Date: Mon, 05 May 2008 10:59:16 +0530 > > > > 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 libra
Re: [Evolution-hackers] Getting rid of shipped libdb
On Thu, 2008-10-09 at 19:10 +0200, Matthias Braun wrote: > > You should respect the lessons learned from mbox format vs. maildir for > mails. Simply use a single file per vcard and make the creation/deletion > performance an issue of the file system which usually deals with this > quiet well. I also want to see flat files; something like a vcard, maybe even an xml version of one put into an RFC. I'd also want the files to default to a new XDG directory for contacts instead of being hidden away in the configuration directory for gnome. (because it's user data, not configuration) I believe there is a new .config directory and probably a new .cache directory for all the stuff programs need to do with those. It'd be nice to sort out the data using a standard like XDG too. Best Regards, Martin Owens ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
Am Dienstag, den 07.10.2008, 16:49 +0100 schrieb Rob Bradford:
> On Tue, 2008-10-07 at 14:22 +0100, Michael Meeks wrote:
> > On Mon, 2008-10-06 at 18:35 +0100, Rob Bradford wrote:
> > > Okay. Have you got these details? It would be good to see which of those
> > > still apply, etc..
> >
> > Sure - the original rational here (AFAIR) is quite simple.
> >
> > If you share the same .evolution across multiple machines, and the
> > version of libstupid is different: bad luck, you loose your contacts.
>
> > Basically all database-y things seem to love back-compatibility ( if
> > you're lucky ), but the idea of forward compatibility seems to
> > completely bypass them; the concept that the functionality is good
> > enough already, and doesn't require further file-format breakage is
> > apparently not present ;->
> >
> > AFAIR the addressbook usages of libdb for the local addressbook were
> > annoying enough in previous instances that we moved to having an
> > internal version.
> >
> > What I'd love to see instead, is a one-shot migration to a simple plain
> > text, authoritative file with the contacts and then (perhaps) optionally
> > a binary cache I guess. But for the volume of data there, presumably
> > slurping it and grokking it with some small / simple piece of code would
> > be rather more efficient. Ultimately contact searches are in response to
> > user-input, so we have loads of time to do work there.
>
> Hhh. But. The use case you outlined directly above about where this goes
> wrong also applies here: "Oh. You ran e-d-s on a machine with a version
> that migrates it to Some Other Format (tm). You then add some contacts
> which go into the new format. Then you go back to your old machine.
> *Boing*. Same problem, your new contacts are missing :-("
>
> Of course you can solve this by keeping the two backends around for as
> long you need (e.g. 1, 2, 3, 5, ..., n-1, n releases) OR you can dictate
> a policy saying that once you've migrated you can never go back.
>
> I would expect migrating from one version of GNOME and then back again
> is probably pretty problematic anyway...ultimately I think you need to
> draw the line at some point.
>
> (You can work around the forward/backward migration by for instance
> having full support in version n, but not migrate the user until (n+k).
> Then if the user goes back to >= n then then they can still access their
> old/new data.)
>
> Somewhat orthogonally: Also, I wonder on the performance impact of the
> flat-file approach wrt, modification / deletion when dealing with ~1k
> contacts.
You should respect the lessons learned from mbox format vs. maildir for
mails. Simply use a single file per vcard and make the creation/deletion
performance an issue of the file system which usually deals with this
quiet well.
Greetings,
Matthias
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
On Tue, 2008-10-07 at 18:14 +0100, Michael Meeks wrote:
> Hi Rob,
>
> On Tue, 2008-10-07 at 16:49 +0100, Rob Bradford wrote:
> > Hhh. But. The use case you outlined directly above about where this goes
> > wrong also applies here: "Oh. You ran e-d-s on a machine with a version
> > that migrates it to Some Other Format (tm). You then add some contacts
> > which go into the new format. Then you go back to your old machine.
> > *Boing*. Same problem, your new contacts are missing :-("
>
> Yes true - but at least, this is a once-and-for-all fix ;-) and of
> course there is no reason to say that we can't sync them to the old db
> format too for a while.
Ack.
> > I would expect migrating from one version of GNOME and then back again
> > is probably pretty problematic anyway...ultimately I think you need to
> > draw the line at some point.
>
> True - but having a problem at -every- version point, and across ~every
> distribution such that "I used SUSE and now I can't switch back to
> FooBaked Linux !" is not good ;-)
Ack. Although i'd have thought we'd have seen more bugs relating to
people upgrading...through several generations e.g. Ubuntu.
> > Somewhat orthogonally: Also, I wonder on the performance impact of the
> > flat-file approach wrt, modification / deletion when dealing with ~1k
> > contacts.
>
> Fast enough I guess; I have ~3k real-life contacts, and that is ~1.5Mb
> of addressbook.db [ which seems pretty much a flat vcard file when you
> read it ;-].
Okay.
>
> It seems my pmap is struggling to work ATM, but it'd be interesting to
> know how much of addressbook.db is 'hot' in e-d-s anyway.
For queries that Evolution does the summary is used quite extensively.
The summary is an in-memory cache which is then serialised out to disk.
Searching is therefore an O(n) strcmp exercise. For just the reading
case i'd expect to find that the database is not very hot since the
summary should help with a lot of the searching. From the summary you'd
get the UID you were lookibg for and then can do an efficient (hashed)
UID based lookup to find the VCARD.
I did some work to replace this with a bdb index:
http://bit.ly/1GrCPL
This had the benefit of being more flexible about the fields you could
index and you get some better performance for queries since you can
exploit the hash to help you find what you're looking for. (As an aside
there is also the memory impact of not having to have the summary in
memory perpetually.)
Cheerio,
Rob
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
Hi Rob,
On Tue, 2008-10-07 at 16:49 +0100, Rob Bradford wrote:
> Hhh. But. The use case you outlined directly above about where this goes
> wrong also applies here: "Oh. You ran e-d-s on a machine with a version
> that migrates it to Some Other Format (tm). You then add some contacts
> which go into the new format. Then you go back to your old machine.
> *Boing*. Same problem, your new contacts are missing :-("
Yes true - but at least, this is a once-and-for-all fix ;-) and of
course there is no reason to say that we can't sync them to the old db
format too for a while.
> I would expect migrating from one version of GNOME and then back again
> is probably pretty problematic anyway...ultimately I think you need to
> draw the line at some point.
True - but having a problem at -every- version point, and across ~every
distribution such that "I used SUSE and now I can't switch back to
FooBaked Linux !" is not good ;-)
> Somewhat orthogonally: Also, I wonder on the performance impact of the
> flat-file approach wrt, modification / deletion when dealing with ~1k
> contacts.
Fast enough I guess; I have ~3k real-life contacts, and that is ~1.5Mb
of addressbook.db [ which seems pretty much a flat vcard file when you
read it ;-].
It seems my pmap is struggling to work ATM, but it'd be interesting to
know how much of addressbook.db is 'hot' in e-d-s anyway.
HTH,
Michael.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
On Tue, 2008-10-07 at 14:22 +0100, Michael Meeks wrote:
> On Mon, 2008-10-06 at 18:35 +0100, Rob Bradford wrote:
> > Okay. Have you got these details? It would be good to see which of those
> > still apply, etc..
>
> Sure - the original rational here (AFAIR) is quite simple.
>
> If you share the same .evolution across multiple machines, and the
> version of libstupid is different: bad luck, you loose your contacts.
> Basically all database-y things seem to love back-compatibility ( if
> you're lucky ), but the idea of forward compatibility seems to
> completely bypass them; the concept that the functionality is good
> enough already, and doesn't require further file-format breakage is
> apparently not present ;->
>
> AFAIR the addressbook usages of libdb for the local addressbook were
> annoying enough in previous instances that we moved to having an
> internal version.
>
> What I'd love to see instead, is a one-shot migration to a simple plain
> text, authoritative file with the contacts and then (perhaps) optionally
> a binary cache I guess. But for the volume of data there, presumably
> slurping it and grokking it with some small / simple piece of code would
> be rather more efficient. Ultimately contact searches are in response to
> user-input, so we have loads of time to do work there.
Hhh. But. The use case you outlined directly above about where this goes
wrong also applies here: "Oh. You ran e-d-s on a machine with a version
that migrates it to Some Other Format (tm). You then add some contacts
which go into the new format. Then you go back to your old machine.
*Boing*. Same problem, your new contacts are missing :-("
Of course you can solve this by keeping the two backends around for as
long you need (e.g. 1, 2, 3, 5, ..., n-1, n releases) OR you can dictate
a policy saying that once you've migrated you can never go back.
I would expect migrating from one version of GNOME and then back again
is probably pretty problematic anyway...ultimately I think you need to
draw the line at some point.
(You can work around the forward/backward migration by for instance
having full support in version n, but not migrate the user until (n+k).
Then if the user goes back to >= n then then they can still access their
old/new data.)
Somewhat orthogonally: Also, I wonder on the performance impact of the
flat-file approach wrt, modification / deletion when dealing with ~1k
contacts.
Cheerio,
Rob
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
On Tue, 2008-10-07 at 14:22 +0100, Michael Meeks wrote: > What I'd love to see instead, is a one-shot migration to a simple plain > text, authoritative file with the contacts and then (perhaps) optionally > a binary cache I guess. But for the volume of data there, presumably > slurping it and grokking it with some small / simple piece of code would > be rather more efficient. Ultimately contact searches are in response to > user-input, so we have loads of time to do work there. vCard would seem like the obvious choice of file formats here, perhaps with in-memory file-offset indices by name and email address? I'm curious: what was the rationale for using a database for local address books in the first place? Matt ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
On Mon, 2008-10-06 at 18:35 +0100, Rob Bradford wrote: > Okay. Have you got these details? It would be good to see which of those > still apply, etc.. Sure - the original rational here (AFAIR) is quite simple. If you share the same .evolution across multiple machines, and the version of libstupid is different: bad luck, you loose your contacts. Basically all database-y things seem to love back-compatibility ( if you're lucky ), but the idea of forward compatibility seems to completely bypass them; the concept that the functionality is good enough already, and doesn't require further file-format breakage is apparently not present ;-> AFAIR the addressbook usages of libdb for the local addressbook were annoying enough in previous instances that we moved to having an internal version. What I'd love to see instead, is a one-shot migration to a simple plain text, authoritative file with the contacts and then (perhaps) optionally a binary cache I guess. But for the volume of data there, presumably slurping it and grokking it with some small / simple piece of code would be rather more efficient. Ultimately contact searches are in response to user-input, so we have loads of time to do work there. HTH, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
On Mon, 2008-10-06 at 22:15 +0530, Srinivasa Ragavan wrote: > 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. I tried to find some details on the Oracle site about any file format guarantees. I couldn't. There is some code in the file backend to try and handle upgrading. I'm not sure how well tested this code path is. Since that the vast majority of users out there have the system libdb dynamically linked into their binaries with apparently no ill effects. However, there hasn't been a major version upgrade (with incompatible file formats) for quite some time. Cheerio, Rob ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
On Tue, 2008-10-07 at 09:00 +0530, Srinivasa Ragavan wrote: > Oh, > > My earlier mail had that as a attachment :-) Eeek. Not enough caffeine. ;-) Cheerio, Rob ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
Evolution in OpenSolaris is still using the bundled BDB since Sun has a license with Oracle that we cannot ship BDB libs/headers in OpenSolaris for now. I do hope this could be changed. But for now, we'd like to still have an option to use the bundled one. Thanks, Harry On Mon, 2008-10-06 at 14:51 -0400, Matthew Barnes wrote: > On Mon, 2008-10-06 at 22:15 +0530, Srinivasa Ragavan wrote: > > 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. > > Just as a data point, E-D-S on Fedora links to the system libdb. > > My understanding is it wasn't so much a fork as a freeze, since I guess > libdb has had trouble maintaining ABI or API stability in the past. I > don't think any significant changes have been made to our bundled libdb > other than build-related and maybe security-related stuff. > > I guess the real question is whether libdb is stable these days. I > don't recall any issues with it over the past year since switching over > to the system library. Would be great to drop both it and our bundled > libical for 2.26. > > Matt > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers -- [EMAIL PROTECTED] Solaris Desktop Group, Sun Microsystems Tel: +86-10-82618200 ext. 82870/ +86-10-62673870 Fax: +86-10-62780969 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
On Mon, 2008-10-06 at 22:15 +0530, Srinivasa Ragavan wrote: > 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. Just as a data point, E-D-S on Fedora links to the system libdb. My understanding is it wasn't so much a fork as a freeze, since I guess libdb has had trouble maintaining ABI or API stability in the past. I don't think any significant changes have been made to our bundled libdb other than build-related and maybe security-related stuff. I guess the real question is whether libdb is stable these days. I don't recall any issues with it over the past year since switching over to the system library. Would be great to drop both it and our bundled libical for 2.26. Matt ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
On Mon, 2008-10-06 at 22:15 +0530, Srinivasa Ragavan wrote: > 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. Okay. Have you got these details? It would be good to see which of those still apply, etc.. If we do decide to keep the included libdb perhaps it would be nice to strip it down to be the bare minimum that it needs to be... Cheerio, Rob ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
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
