Bug#741501: RFS: libb2/0.96-1 [ITP]
On 2014-03-31 12:37, Robert Ransom wrote:
> On 3/20/14, Christian Kastner <debian@kvr.at> wrote:
>> 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.
I submitted a bug for the duplicate section issue, see #743233. The
debhelper version issue has already been reported as #730741.
Also, please note that dh-make, while very helpful, is not an
authoritative tool. Packages should adhere to the Debian Policy and
other authoritative standards regardless of how the packaging was generated.
>> 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 provides such an infrastructure. The following link should get
you started, if you are interested:
https://wiki.debian.org/Alioth/PackagingProject
>> 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.
See my remark regarding dh-make above.
> * 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.
The driving idea behind the copyright format 1.0 (to which the Format
field refers) is for it to (also) be machine-readable. So while you are
correct in the sense that a human reader might easily deduce this
information, an automatic parser will probably not, so there is indeed a
benefit to including this 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.
That notice includes the "use without restriction", which includes
dropping that useless notice.
"Useless" because even without the notice, the trivial content of that
file would almost certainly not be copyrightable, which is also why it
was removed in version 0.63. See #721849.
>> 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.
Fair enough, although I'd like to point out that the major problems seem
to come from C++ code, which your library isn't.
Speaking for myself, I found that maintaining symbols files for C is
quite easy, and C++ really is just a burden.
>> 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.
Oh, sorry then. Thank you for pointing this out.
Regards,
Christian
Reply to: