[mapguide-internals] Berkeley DBXML native libraries on Linux

Martin Morrison martin.morrison at edsi.com
Thu May 20 10:50:28 EDT 2010


Just make sure the docs are clear and update to date.  By clear, I mean legible by the lowest common denominator, by sysadmins like myself. 

Martin Morrison
Application Engineer
Engineering Design Systems, Inc.
3780 Peters Creek Rd Ext SW
Roanoke, VA  24018
540.345.1410
gis.edsi.com

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Robert Bray
Sent: Thursday, May 20, 2010 10:08 AM
To: 'mapguide-internals at lists.osgeo.org'
Subject: Re: [mapguide-internals] Berkeley DBXML native libraries on Linux

Trevor,

I prefer option 3. It's much more inline with the way other open source projects manage dependences.


Bob

----- Original Message -----
From: mapguide-internals-bounces at lists.osgeo.org <mapguide-internals-bounces at lists.osgeo.org>
To: MapGuide Internals Mail List <mapguide-internals at lists.osgeo.org>
Sent: Thu May 20 06:59:50 2010
Subject: [mapguide-internals] Berkeley DBXML native libraries on Linux

Hi everyone,

Rohit has been working on switching to native libraries for Berkeley DB, Berkeley DBXML, xerces, xalan, and xqilla.  As it turns out, Berkeley DB is the only library included in most distributions:

Berkeley DB - included in most distros
Berkeley DBXML - not included in any distro Xerces - included in Ubuntu only Xalan - included in Ubuntu only xquilla - included in Ubuntu only

Furthermore, Oracle does not release binaries for these libraries on Linux.  They do package Windows installers though.


I think we have a few of options:

1. Keep Berkeley DBXML and all dependencies in our vault and upgrade as required.

2. Build and distribute binaries and headers for the various packages.

3. Document where to get the required source code and let our user base build the required components.


Options 1. and 2. put the onus on us to maintain the components.  Option 1 will continue to clog up our source tree and makes it more difficult to share components with FDO.  Option 3 is a trade off.  It makes it more difficult to build MapGuide but is more flexible and allows us to share components with FDO.

Any thoughts?  Other suggestions?

Regards,
Trevor



More information about the mapguide-internals mailing list