[oi-dev] 1262 Berkeley-db package
Bayard G. Bell
buffer.g.overflow at gmail.com
Tue Oct 4 01:09:14 UTC 2011
On Mon, 2011-10-03 at 19:05 -0400, Alex Viskovatoff wrote:
> On Mon, 2011-10-03 at 23:31 +0100, Bayard G. Bell wrote:
> > Ubuntu, for example, delivers libdb4.6, libdb4.7, and libdb4.8 for
> > libraries. (I'm running BackTrack 5, which is based off 10.04, so this
> > is a bit dated.) The distro simply doesn't deliver any links to the
> > libraries, so everything has to decide which version to link against by
> > both major and minor version. I've ended up with one each for the core C
> > runtime because I have essentially three packages, each using a
> > different version. I've seen similar things in other porting
> > environments, which leads me to suspect that, if there's a nuisance
> > argument, it's that, as a porting system carries more packages, it
> > decides the greatest nuisance is forcing them all to use one version of
> > BDB.
I didn't entirely clarify that I have three dependent packages, one for
each version of BDB.
> > For such reasons, I don't think there are any conventions here that need
> > to be established anew.
>
> Good. I didn't realize it was that simple to deal with this.
>
> And this makes the existence of a bdb package in oi-sfe irrelevant,
> since SFE has not addressed the issue of the need for multiple versions.
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.
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)?
More information about the oi-dev
mailing list