Re: RFS: dnshistory (updated package)

[Matthias Julius <mdeb@julius-net.net>]

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?

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

Matthias