Bug#741501: RFS: libb2/0.96-1 [ITP]
On 3/20/14, Christian Kastner <debian@kvr.at> wrote:
> Hi,
>
> On 2014-03-13 05:57, Robert Ransom wrote:
>> I am looking for a sponsor for my package "libb2":
>
> I'm not a DD so I can't sponsor your package, but here is a quick review:
>
>
> Building
> ========
>
> There is one troublesome aspect of the upstream code: AFAICT,
> CPU-specific optimizations such as MMX, SSE, etc. are detected and
> enabled at compile-time.
>
> That is a problem because your binary packages will end up with
> optimizations specific to the buildd they were built upon, but the
> platforms they will run upon might lack support for those optimizations.
>
> I suggest you either verify that this is not a problem (eg run-time
> support detection) or disable some of those optimizations.
>
> The debian-kernel@l.d.o will probably be able to you which instruction
> sets you are allowed to assume as always present in certain
> architectures (eg "amd64 always has MMX" or some such).
The --enable-fat configure option enables libb2's run-time CPU feature
detection code.
> debian/control:
> ==============
>
> Build-Depends: debhelper (>= 9), not debhelper (>= 9.0.0). IIRC there
> exists a (written or unwritten) rule for when one can/should truncate
> version numbers, but I can't find a source for that at the moment so I
> could be wrong. Regardless, debhelper(7) recommends this.
>
> You do not need to specify the Section: for binary packages if the
> intended Section matches the source package section, so the "Section:
> libs" can be omitted from binary package libb2-1.
dh-make-0.61 generated the duplicate Section field and a “debhelper
(>= 8.0.0)” Build-Depends item. dh-make-0.63 appears to still
generate these. When I upgraded the package to debhelper 9 for
multi-arch support, I changed only the major version number, under the
assumption that dh-make would not have added the “.0.0” unnecessarily.
If the changes you suggest are worth making, they are worth making in
dh-make first.
> If you're using a VCS for your packaging, it would be nice if you could
> include Vcs-* URLS pointing to the repository. This simplifies
> contributing to your packaging.
I am not using a version-control system for this package. I would not
have a trustworthy place to publish a version-control repository for
this package even if I were using a VCS.
> debian/copyright:
> =================
>
> I'd add the Upstream-Contact field to the header section using the
> address you specified in the ITP.
* dh-make-0.61 and dh-make-0.63 do not include an Upstream-Contact
field in the copyright files they generate.
* The e-mail address specified in the ITP bug for this package is
hosted on the same domain name as the upstream web site (which is
specified in the copyright file and which lists more complete
contact information for the upstream maintainers), so in the
specific case of this package, I see no possible benefit to
including that e-mail address in an Upstream-Contact field.
> debian/rules:
> =============
>
> You can drop the "Sample debian/rules that uses debhelper" part.
I'm not willing to remove the attribution from that file.
If the dh-make template authors do not want their work attributed to
them, they can modify dh-make to not copy that notice into its output.
> Later releases (somewhat more advanced topics)
> ==============
>
> You could generate minimal dependencies by creating using a symbols
> file, see
>
> https://wiki.debian.org/UsingSymbolsFiles
According to that page, adding a symbols file and maintaining it
imperfectly is worse than not including a symbols file at all. Since
this package is security-critical and I don't expect it to have
frequent updates, I would prefer to not add a symbols file for it.
If upstream does start to release new versions frequently, I will
consider adding a symbols file.
> You could install lintian overrides to silence a couple of informational
> and pedantic warnings, see
>
> $ lintian -I --pedantic *.deb *.dsc
It is inappropriate to add overrides for lintian messages at info
level or below. Info-level messages might be of interest to other
developers, or might be raised to warning or error level in the future
due to policy changes. The lintian man page specifically recommends
against adding overrides for ‘pedantic’ messages.
Robert Ransom
Reply to: