Hi, Quoting Guillem Jover (2016-03-29 00:39:01) > On Fri, 2016-03-18 at 23:05:26 +0100, Johannes Schauer wrote: > > I thus think it's reasonable for dpkg-genchanges to only include the binary > > packages in the Binary field of the .changes file which were actually > > produced depending on the currently active profiles. > > While that's all true, it unfortunately does not match reality. The > Binary field in the .changes file has always listed all packages > regardless of restrictions, including architectures ones. > > So the bug report seems reasonable, but I hesitate to do the change as > it might break things expecting the field to list more packages than it > should. I'll bring it up on d-d to canvas possible problems.
I just made three uploads of src:botch to unstable:
1. An upload of source and Arch:all but the Binary field only listing the
Arch:all package botch-doc
2. A source-only upload but the Binary field being empty
3. A source-only upload without the Binary field
It seems that the first two instances resulted in successful uploads as one can
see here:
1. https://tracker.debian.org/news/799443
2. https://tracker.debian.org/news/799448
The third one resulted in:
Subject: botch_0.18-6_source.changes REJECTED
botch_0.18-6_source.changes: misses mandatory field Binary
Thus, I do not think that following policy and only putting package names of
packages that are actually produced into the Binary field of the .changes file
should pose any problem. Just take care to not remove the Binary field but
leave it empty if no binary packages are being uploaded.
This finding is also backed up by the dak source code which seems to only check
if the Binary field does *not* list some of the packages that are being
uploaded. See the class BinaryCheck in daklib/checks.py.
Thanks!
cheers, josch
signature.asc
Description: signature
