Hi, On Fri, 18 Mar 2016 20:11:19 +0100 Samuel Thibault <[email protected]> wrote: > A solution would be that dpkg-genchanges is added a -P parameter, and by > default (unstaged) not include staged-only binary packages in Binary. > > [...] > > We then had to pass NEW due to this addition, because the .changes > file had it in the Binary: field. And then we had to pass NEW again > in the latest upload, for the same reason: apparently between the two > uploads some cleaning process in ftp-master had dropped the knowledge > of the package, probably because it's not actually uploaded in the > archive. Perhaps ftp-master should be more cautious about this, but I'd > say dpkg-genchanges should just not even mention this package, what do > you think?
Policy ยง5.6.19 [1] says the following about the Binary field: | When it appears in the .dsc file, it lists binary packages which a source | package can produce, separated by commas[43]. The source package does not | necessarily produce all of these binary packages for every architecture. The | source control file doesn't contain details of which architectures are | appropriate for which of the binary packages. | | When it appears in a .changes file, it lists the names of the binary packages | being uploaded, separated by whitespace (not commas). I think the above can easily be made compliant with the concept of build profiles. In a .dsc file, the Binary field will list all binary packages the source package can possible produce irrespective of architecture (as above) and irrespective of build profiles (analogues to architectures). When it appears in a .changes file, the meaning of the Binary field is a different one and means "I'm hereby uploading these binary packages". So I think it's reasonable to let this field reflect that a package built without any build profiles active will also not upload any binary packages specific to a certain build profile. 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. Thanks! cheers, josch [1] https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Binary
signature.asc
Description: signature
