Re: RFS: dnshistory (updated package)

[Paul Wise <pabs@debian.org>]

On Thu, Apr 30, 2009 at 9:21 PM, Matthias Julius <mdeb@julius-net.net> wrote:
> Matthias Julius <mdeb@julius-net.net> writes:
>
>> Paul Wise <pabs@debian.org> writes:
>>
>>> I don't see anything in the maintainer scripts that would migrate the
>>> db files. Does dnshistory or libdb handle upgrading the on-disk db
>>> format? Or can libdb handle older versions of the on-disk db format?
>>
>> I was assuming the latter.  But, reading
>> http://www.oracle.com/technology/documentation/berkeley-db/db/ref/am/upgrade.html
>> this does not look like a safe assumption.
>
> According to
> http://www.oracle.com/technology/documentation/berkeley-db/db/ref/upgrade/process.html
> it is not even safe to assume that the API of a new major or minor
> version is backwards compatible.  This means that a binNMU triggered
> by a libdb transition may cause the application to FTBS or not to work
> correctly.
>
> Therefore, I am beginning to think that build-depending on libdb-dev
> is not such a good idea.
>
> I am considering to build-depend on libdb4.7-dev to address a number
> of issues:
> - dnshistory can be tested when it is to be rebuilt with a new libdb
>  version
> - when the database files need to be upgraded this can be mentioned in
>  debian/NEWS
> - this allows to skip a couple of libdb versions potentially saving
>  the users unnecessary database upgrades.
>
> Of course, this means there will be a new upload necessary every time
> the libdb version used is supposed to be dropped from the archive.
>
> Are there other reasons why I should not do that?

I'll let the NMUer and the libdb maintainer answer that (BCCed).

> Is there a convenient way to find all reverse build-depends of a
> package?

build-rdeps from the devscripts package.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise