[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


Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

2008-10-06 Thread Chenthill
I was not able to try the upstream libical yet. I am right now packed
with some other work, so I will try to get this done as soon as
possible.  Suddenly the weekends have gone out of my hands as I have to
move out of station to places that do not have internet connectivity.
Either me or suman will make the changes and get the work done for
2.25.1 if the time is sufficient to get libical as a external dependency
for GNOME 2.25.1. We would test the library and let you know before oct
17th.

thanks, Chenthill.
On Fri, 2008-09-19 at 14:41 +0530, Chenthill wrote:
 On Thu, 2008-09-18 at 22:52 -0400, IGnatius T Foobar wrote:
   I have applied Chenthill's memory management patches (only to the 
   'libical' directory and to the examples -- still have to do the 
   'libicalcap' and 'libicalss' directories) using function names ending in 
   _r.  
   IMHO, HANDLE_LIBICAL_MEMORY can be removed.
 
  
  Ok folks, it's done ...
  
  The remaining portions of libical (libicalcap and libicalss) have been 
  converted to the _r API.   (The test suite still uses the old API and 
  will continue to do so for a while.)
  
  Now is the time for Evolution code to be updated to use the new calling 
  syntax.
  
  Is there anything we can do to facilitate this, or should we just hang 
  out and wait for you folks to kick the tires on the new library?  Let me 
  know...
 I will make the changes and test it over this weekend.
 
 thanks, Chenthill.
 
 ___
 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