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