Re: [Evolution-hackers] db3 and db4



On Wed, 2003-11-19 at 08:53, Christopher Smith wrote:
> On Wed, 2003-11-19 at 05:35, JP Rosevear wrote:
> > This is the real reasons we need to import it - incompatible db
> > formats.  As far as we could tell the DB people change formats between
> > minor versions (at least they did for the 3.x series) and then don't
> > version the libraries properly so its hard to account for binary
> > compatability.  If we dynamic linked it means it might be impossible to
> > move you .evolution dir to another machine if that machine's evo was
> > linked to an older DB.  I don't want various source trees proliferating
> > either, but I don't see a better solution at this point.
> 
> For Sleepycat's statements on this:
> 
> http://www.sleepycat.com/docs/ref/upgrade/process.html
> 
> "Berkeley DB major and minor releases may optionally include changes in
> all four areas, that is, the application API, region files, database
> formats, and log files may not be backward-compatible with previous
> releases."

Ok, so not 4.1.1 to 4.1.2, but possibly with 4.1.1 to 4.2.0.

> and
> 
> "A Berkeley DB patch release will never modify the API, regions, log
> files, or database formats in incompatible ways, and so applications
> need only be relinked (or, in the case of a shared library, pointed at
> the new version of the shared library) to upgrade to a new release."
> 
> I'm not sure what you mean by "they don't version the libraries
> properly".

There is a system for versioning libraries (at least this is how libtool
requests it be done and how many libraries do it) using CURRENT, AGE,
REVISION which allows you to make statements about the binary
compatibility of the library.  Last I checked DB inserts the version of
the db for the library .so numbers so you can't infer anything about bin
compat.

-JP
-- 
JP Rosevear <jpr ximian com>
Ximian, Inc.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]