[oi-dev] 1262 Berkeley-db package

[Josef 'Jeff' Sipek]

On Mon, Oct 03, 2011 at 06:06:47PM +0100, Bayard G. Bell wrote:
> A few items, as much questions as anything else:
> 
> 1) given that you usually end up needing multiple bdbs, should the
> standard here be to embed version components into the name?

Yeah... does pkg:/database/bdb-4.8 sound better?

> 2) is there any basis for thinking that bdb should only be built for
> 32-bit support, or would we reasonably expect that 64-bit binaries would
> need to link against it?

To give credit where credit is due...I based the package name and the lack
of 64-bit build on oi-sfe. :)

I'm all for building it as both 32 and 64 bit.  If that turns out
non-trivial, would anyone be opposed to getting a 32-bit build in, and then
in a separate commit adding 64-bits build?

> 3) it looks like the default behaviour for library link generation is to
> create links that look like lib<name>-<version>.so rather than
> lib<name>.so.<version>; which convention is expected for OI?

I've noticed that this is Berkeley-db's way of doing things.  On a Linux
box that I have, lib<name>-<version>.so is used too.

I suppose if we include the version number in the package name, then
lib<name>.so would just work.

> 4) a lot of the content appears to be documentation; have you confirmed
> that all of it is correctly tagged with the doc facet?

Will do.

> 5) I notice that there's documentation for csharp, but I wouldn't expect
> that to be applicable to our build; if that's the case, is there
> anything we can do to suppress the generation of such documentation
> (stripping out of the manifests might also be an option)?

The sfe package has it.  I don't particularly care either way.

> 6) given the prevalence of bdb and how low it tends to be in the stack,
> might we also consider providing debug support? are there any standing
> rules on how that should be done?

No clue.

Jeff.

-- 
My public GPG key can be found at
http://www.josefsipek.net/gpg/public-0xC7958FFE.txt