[pkg-db-devel] Bug#622916: libdb4.7-dev: please reinstate -ldb support

[Niko Tyni]

(switching the perl package CC to #621383)

On Sun, Apr 17, 2011 at 12:52:53PM +0200, Ondřej Surý wrote:
> On Sat, Apr 16, 2011 at 06:11, Niko Tyni <ntyni at debian.org> wrote:
> > On Fri, Apr 15, 2011 at 11:29:21PM +0200, Ondřej Surý wrote:
> >> Niko, could you change the linking from -ldb to -ldb-4.7 instead? The
> >> linkable .so file is provided by libdb4.7 package.

> > Still, I dislike having to apply this. Given a move to db4.8 is much
> > less risky than 5.x, should we do that for the time being or are you
> > going to do the same thing to libdb4.8-dev next?
> 
> I would like to do this to db4.8 too (but much much later on).

I see. I suppose in that case we just need to bite the bullet.

> Anyway I don't think the move from 4.7 to 4.8 is any less riskier than
> move from 4.7 to 5.1. The 4.x vs 5.x is nothing more than inability to
> have 4.10 version number. Both require log format upgrade - See:
> http://www.oracle.com/technetwork/database/berkeleydb/downloads/index-082944.html

Thanks, no point in that approach then.

> >> I just wanted to make linking to libdb-4.7 explicit, not to prevent
> >> linking at all.
> >
> > I don't really see the advantage. The maintainers of the dependant
> > packages are (hopefully) already aware of the transition, why the need
> > to push them? Are you worried that new packages pick db4.7 by accident?
> 
> Well, my reasoning is that if you want to depend on specific bdb
> version, you need to be able to link with that specific version.

The old way worked perfectly for us. The upstream code is able to link
against any version with just -ldb, and we could control that in Debian
with just the Build-Depends field.

Now we need to also patch the upstream source to accomplish this, and keep
the patch up to date when upgrading between upstream versions. Pushing
the patch upstream isn't likely to go well as this is purely a Debian
specific problem and -ldb works fine for everybody else.

I'm attaching a generalized version of your patch that allows setting
$DEBIAN_DB_VERSION in the environment so that at least we don't have to
update the patch every time we change the db version. There's no need
to patch DB_File as it prefers the environment variable $DB_FILE_NAME
if that is set.

I'm somewhat inclined to just throw in the towel, switch to libdb-dev
(Ubuntu already does), and let somebody else worry about db transition
risks. It's not like I know much about them anyway.

Dominic, please let me know what you think.

> >> However I gladly revert the change if it will be too big obstacle.
> >
> > Please do.
> 
> I'll revert the change for now and I will prepare more detailed
> schedule when I will reintroduce this move, so all packages can
> prepare.

Thanks for this.
-- 
Niko Tyni   ntyni at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: explicit-db-version.diff
Type: text/x-diff
Size: 3207 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-db-devel/attachments/20110417/9bce5fec/attachment-0001.diff>