Re: [Evolution-hackers] Getting rid of shipped libdb

2008-10-09 Thread Matthias Braun
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

2008-10-09 Thread Martin Owens
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

2008-10-09 Thread Jeff Cai
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 evolution-hackers@gnome.org
  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 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 

Re: [Evolution-hackers] Getting rid of shipped libdb

2008-10-08 Thread Rob Bradford
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

2008-10-07 Thread Michael Meeks

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

2008-10-07 Thread Rob Bradford
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

2008-10-07 Thread Rob Bradford
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

2008-10-07 Thread Matthew Barnes
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

2008-10-07 Thread 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.

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

2008-10-07 Thread Michael Meeks
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


[Evolution-hackers] Getting rid of shipped libdb

2008-10-06 Thread Rob Bradford
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


Re: [Evolution-hackers] Getting rid of shipped libdb

2008-10-06 Thread Srinivasa Ragavan
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
---BeginMessage---
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


Re: [Evolution-hackers] Getting rid of shipped libdb

2008-10-06 Thread Rob Bradford
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

2008-10-06 Thread Matthew Barnes
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

2008-10-06 Thread Harry Lu
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