Clint Adams <sch...@debian.org> writes: > 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.
Thank you for your explanation. I will keep it as it is then. And since the database format did not change from 4.6 to 4.7 there should be nothing for the user to worry about. I will take care of the other issues and upload a new package to mentors soon. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org