[oi-dev] 1262 Berkeley-db package

[Alasdair Lumsden]

Hi Bayard,

On 4 Oct 2011, at 02:09, Bayard G. Bell wrote:
<snip>
> If OI decides now is the time to start delivering, let's at least check
> for other areas of overlap and make sure that we're standing solidly on
> your shoulders. In particular, how about other questions raised, such as
> delivering debug and multiple bitness versions? Also, since the docs
> pointed to the question of language bindings, we really should decide
> whether the same component in oi-build should deliver bindings other
> than the basic C stuff and divy up documentation with the appropriate
> library packages.

Debug builds - tbc. Is it possible to deliver multiple versions of the same file with IPS, eg if you had a debug facet or something (straying past the edge of my IPS knowledge here).

Multiple bitness - the convention is that libraries or packages that benefit from 64bit should be shipped as a combined 32bit/64bit. BerkeleyDB classifies as a system library so should ship with 64bit. Apache/MySQL/PHP also qualify as deserving 64bit versions. XCowsay or mutt for example would be fine as 32bit only.

Dropping documentation for bindings we don't deliver seems completely reasonable to me! :-)

> Looking quickly at my Ubuntu/BT systems, it looks like they package
> java, tcl, and c++ libraries separately for each libdb release. Should
> we do the same, plus providing debug facets or variants? (I assume that
> the dynamic languages provide their own libraries, possibly in the core
> release.) Putting the question more broadly, what expectation do we have
> about providing debug libraries, particularly for things taken to be
> common/pervasive (I'm asking a leading question, as I'm wondering if we
> ought to try to bake some form of debug support simplification into the
> Makefile infrastructure)?

Is this BerkeleyDB commit just the pure C bindings or does this package cover C++, Java and TCL as well?

The debug question sounds like more hassle than it's worth at this point. The urgent need is for updated and additional packages. Debug support is just going to add more work to the packaging procedure. Potentially in the future it's worth adding but I'd prefer to keep the packaging procedure lightweight right now and try to build up the volume of commits/maintainers/contributors. Then we can start throwing additional work at them :-D

Potentially if someone wants debug support badly, they can check out oi-build and rebuild the package in question themselves, since the idea is that oi-build should be super-easy to use.

Cheers,

Alasdair