On 2019-02-03 17:21:35, Antoine Beaupre wrote:
> My first submissions for the dmarc-cat package (#920385) were refused
> by the FTP masters because the built-using field did not respect §7.8
> of the Debian policy.
That's actually inaccurate: the package was refused because the
dependencies specified in `built-using` were missing and indeed, one of
the dependencies hadn't passed NEW when dmarc-cat was uploaded. For
example, here's the last REJECTION I had:
An exception was raised while processing the package:
Traceback (most recent call last):
File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 109, in
wrapper
function(upload, srcqueue, comments, transaction)
File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 222, in
comment_accept
extra_archives=[upload.target_suite.archive],
File "/srv/ftp-master.debian.org/dak/dak/daklib/archive.py", line 451, in
copy_binary
self._ensure_extra_source_exists(filename, db_source, archive,
extra_archives=extra_archives)
File "/srv/ftp-master.debian.org/dak/dak/daklib/archive.py", line 245, in
_ensure_extra_source_exists
raise ArchiveException('{0}: Built-Using refers to package {1} (= {2}) not
in target archive {3}.'.format(filename, source.source, source.version,
archive.archive_name))
ArchiveException: d/dmarc-cat/dmarc-cat_0.9.1-1_amd64.deb: Built-Using refers
to package golang-github-ivpusic-grpool (= 1.0.0-1) not in target archive
ftp-master.
When grpool was ACCEPTED, dmarc-cat also was ACCEPTED by the
FTP-masters. So this is not a blocker for the FTP masters.
> Extract from #debian-ftp:
>
> 16:55:59 <jrtc27> Built-Using is only meant to be used when the result is
> GPL/MPL/similar and you've statically linked (/bundled) another source package
> 16:56:33 <anarcat> okay, so to comply with licensing issues?
> 16:56:47 <anarcat> it also seems useful to track rdeps for golang as well, no?
> 16:57:03 <waldi> no, built-using is _not_ for tracking dependencies
> 16:57:10 <waldi> it is for license compliance
> 16:57:26 <waldi> and bsd licensed software does not require that
>
> So in the case of dmarc-cat, dependencides like
> golang-github-stretchr-testify-dev should actually not be listed in
> the Built-Using field.
It's true, however, that the Debian policy specifies built-using is for
copyright reasons.
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
Specifically, the last pargraph reads:
> This field should not be added solely for purposes other than
> satisfying license or DFSG requirements to provide full source
> code. In particular, it should not be added solely to enable finding
> packages that should be rebuilt against newer versions of their build
> dependencies.
Yet, from what I understand, that is *exactly* how that field is used in
the golang team. Is that correct?
It should be noted this is a SHOULD NOT and not a MUST NOT, so it's a
little more relaxed - may we are allowed to abuse it like this.
I do wonder if it's deliberate, however. It seems to me this should be
clarified, both in dh-golang and in policy, either way.
A.
--
Perl is "some assembly required". Python is "batteries included". PHP
is "kitchen sink, but it’s from Canada and both faucets are labeled C".
- Alex Munroe, PHP: a fractal of bad design
