Hi! On Thu, 2016-09-22 at 13:35:23 +0200, Johannes Schauer wrote: > 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.
It seem that ended up not eliciting any additional input, except for Samuel's. :( > 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. Thanks for these tests, much appreciated! I've got now a patch locally which only includes binary names and descriptions for binaries actually uploaded. I'm tempted to just apply it, although it would first need for dak to not reject an upload when the Binary field is missing. I've got a patch here for dak too, which I'll send out tomorrow. > 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. Right, that's my reading too. Samuel, the bad news, I'm afraid, is that even with that change, this would not solve your original problem, because dak uses the Package-List field from the .dsc which will include all possible binary names. I think what you'd need is for dak itself to ignore packages that are only built on specific profiles (this can be checked from the Package-List field). At least that's what I'm reading from the dak sources, but perhaps I've missed some code. You might want to try the problematic upload but removing the entry only from the Package-List field, keeping the entries in the .changes Binary field, and see what happens. Thanks, Guillem
