Re: RFS: dnshistory (updated package)
Paul Wise <email@example.com> writes:
> You build-depend on libdb-dev, in sid that depends on libdb4.7-dev but
> the current dnshistory package is built against libdb4.6. Should you
> add another debian/NEWS entry about this? I'm not sure what to do in
> this situation, could you investigate?
I am not quite sure how to deal with that one. Since Luk Claes NMUed
the package to change the Build-Depends from libdb4.4-dev to libdb-dev
I don't really have control over which libdb version dnshistory is
built against. If it happens that a new libdb is uploaded before
dnshistory has been built on all archs or if a binNMU is triggered by
a libdb transition debian/NEWS will be outdated.
I wonder how other packages build-depending on libdb-dev handle this.
That entry in debian/NEWS is somewhat special in that the dependancy
on libdb had been downgraded from 4.5 to 4.4 in order to allow
dnshistory to migrate into testing (etch at the time) and libdb4.5 was
being kept out.
On upgrade I would expect db files to be migrated if necessary.
> Only the above is a blocker, some other things you may want to look at:
> Please use $(QUILT_STAMPFN) instead of patch in debian/rules.
> Please make build-stamp depend on configure-stamp.
> ./configure gets run twice on my machine in pbuilder due to the above
> two issues.
I will take care of that.
> For some reason the mktime test in ./configure takes ages and a lot of
> CPU in pbuilder and then fails.
As explained by Sven this is due to an outdated ./configure. What is
the best way to deal with that? Ignore? Run autoconf from
debian/rules? Bug upstream?
> I get one dpkg-shlibdeps warning, please ask upstream to remove -lm
> from the link flags:
> dependency on libm.so.6 could be avoided if
> "debian/dnshistory/usr/bin/dnshistory" were not uselessly linked
> against it (they use none of its symbols).
How important is this? I doubt upstream will release a new version
just to fix those minor issues.
> I get one lintian pedantic complaint:
> P: dnshistory: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
Good catch, I will fix that, too.
> You might want to review the debtags and upload a screenshot:
Since this is a console application and not primarily meant to be run
directly by the user a screenshot is probably not very beneficial.
Thanks for reviewing my package.