> > 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. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org