sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] SKS debian package


From: Jeffrey Johnson
Subject: Re: [Sks-devel] SKS debian package
Date: Mon, 23 Apr 2012 18:59:14 -0400

On Apr 23, 2012, at 6:25 PM, Christoph Anton Mitterer wrote:

> On Sat, 2012-04-21 at 14:56 -0400, Jeffrey Johnson wrote:
>> And the recommended -- by SleepyCat -- solution is to internalize
>> Berkeley DB to avoid breakage between different applications
>> compiled against different libraries.
> 
> With internalise you mean that the package should ship it's own copy of
> BDB?

Yes.

> Then I'd generally suggest against... this is basically static linking
> and for all well known reasons, should be only used in very very very
> rare circumstances.

And your opinion is contrary to what was recommended.

The tradeoff is whether you want to maximize application
independence from Berkeley DB or minimize efforts when updating everything
that uses "system" Berkeley DB.

Statically linking Berkeley DB was claimed to be ~175K 
when tuned for a minimal memory footprint without all
the bells and whistles. The code footprint in memory is
certainly small.

Compiling the utilities is a different matter. The tools
would need to be linked with a single, not multiple,
copies of Berkeley DB. Its not too hard to change
main() in each of the utilities, and then use argv[0]
to select which utility is needed.

There's code in RPM to statically link all utilities
against a single library version using argv[0] if anyone is interested.

So utilities+application would involve 2 versions of
the libraries coming in (iirc) at about 175KB for each
copy of the library.

I don't know whether 175KB is still accurate: but Berkeley DB
isn't huge by any means.

73 de Jeff



reply via email to

[Prev in Thread] Current Thread [Next in Thread]