Re: RFS: dnshistory (updated package)
> > 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).
Typically the fear which motivates this type of question is unfounded.
Looking at the dnshistory source code, it appears that the use of BDB
is trivial. Generally when the feature set you require could just
as easily have been satisfied by GDBM, there are rarely compatibility
worries. dnshistory is using simple B-trees, which haven't changed
incompatibly in over 5 years.
If, in a future BDB version, the database file created by dnshistory
is using too old a format, the attempt to open it would return
DB_OLD_VERSION, and you could add code to dnshistory to DB->upgrade()
the file, seamlessly resolving the issue.
It would be a different story if dnshistory were using transactions
or other subsystems.
I believe this is a clear case of build-depending on libdb-dev being
the proper solution.
Reply to: