Re: How about a db 5.1.25 backport
On Tue, Apr 19, 2011 at 19:20, Andreas Metzler
<ametzler@downhill.at.eu.org> wrote:
> On 2011-04-18 Gerfried Fuchs <rhonda@deb.at> wrote:
>> * Andreas Metzler <ametzler@downhill.at.eu.org> [2011-04-17 13:46:58 CEST]:
>> > I am considering uploading a backport of berkeley db 5.1.25. Packages
>> > in sid are (supposed to be) switching from 4.8 and later to 5.1, which
>> > is not available in squeeze, making backports hard.
>
>> It makes backports hard in the way that to work around the issue you
>> raised the backport will require a versioned dependency on libdb-dev. If
>> that's clear for everyone involved then it's fine with me, but I fear
>> the issue will be moved to a different level.
>
> Hello,
>
> Afaiui the db using packages (should) fall in two camps:
>
> 1. Packages with an unversioned (or >= squeeze) build-dependency on
> libdb-dev. (Probably >= 3.2) They can be switched to new bdb by
> binNMUing and therefore must automatically handle file format upgrades
> in their maintainerscripts, without relying checks of the package
> version.
>
> 2. Packages build-depending on the the versioned -dev packages (e.g.
> libdb4.8-dev). Database upgrades only happen when the maintainer wants
> them to happen, since they require a sourceful upload. The maintainer
> can add custom handholding for each b-d update in its maintainer
> scripts.
>
> I currently fail to see how adding db 5.1 to backports.org breaks either
> of these: The packages in 1. will usually not have b-d on the backported
> db package, and will therefore be built against squeeze's db. The
> packages in 2. will suddenly be backportable in straightforward way,
> without big source changes.
>
> Your point seem to be rather new broken packages in sid. - They have
> been uploaded recently with an unversioned libdb-dev b-d without
> handling db upgrades. This bug has not yet been triggered in sid,
> because not db upgrade has hit them.
>
> Did I understand the point correctly?
But the world is not that simple. There are packages which depend on
unversioned libdb-dev and have to handle database upgrades. Or they
simply break with db5.1 (f.e. when binNMUing - f.e. libdb-ruby), or
they build with db5.1 headers and db4.8 library (xastir and some other
software which uses autoconf macros like this: "for db in db-4.8 ...
db; do").
I would say that you should wait for db5.1 version which will remove
generic symlinks from libdb5.1*-dev packages and move them to
unversioned package. Which I plan to do after the db5.1 transition is
done. That way we will make sure that no package is switched to db5.1
unless it explictly wants to.
O.
--
Ondřej Surý <ondrej@sury.org>
http://blog.rfc1925.org/
Reply to: