Hi! On Fri, 2017-01-27 at 15:58:30 +0000, Ian Jackson wrote: > Package: dpkg-dev > Version: 1.18.19
> I think this changes is risky: > > * Stop emitting Built-For-Profiles from dpkg-gencontrol. The information > is already provided in .buildinfo files, and including it in the binary > packages makes them unreproducible even when the profile used would not > alter its contents. Closes: #831524 > > This significantly reduces the amount of information available to > understand why a .deb might be the way it is. It also inhibits the > ability of the archive to reject oddly-built binaries. Not really. This information has been provided in the .changes file (which is not exposed by the Debian archive), and recently by the .buildinfo file, which is supposed to be made publicly available. So the archive software should have (had) enough information to reject uploads built with any build-profile. I see I didn't make this clear in the changelog message, and I further notice that deb-changes(5) does not document the field. I've corrected the latter locally, and I might also amend the changelog entry. > IMO this ought to have been dealt with properly, by introducing the > concept of dirty and clean build-profiles, as suggested before on > debian-devel. > > This change ought to have been discussed more widely, I think. I think I've actually been one of the people reluctant to see that field go from the .deb packages. The main reason being that I considered being able to see, from a standalone .deb, whether it had been built with certain profile as useful. But a standalone .deb, w/o any archive context might have been built in any environment imaginable, which is also the case with binary uploads in the archive. So, after reflection this reason seemed a bit pointless. Also given that this information is already in both the .changes and .buildinfo files, it seems sufficient to make archive decisions based on that. So, I did canvas opinions on the #debian-dpkg IRC channel, and people seemed fine with the idea. It also makes reproducible builds and other QA and porting efforts more useful. I could have certainly brought this up on the list, but TBH as it seemed pretty uncontroversial, that's why I didn't end up doing that. OTOH designing and implementing any kind of dirty/clean profile tracking seems more controversial as was seen on the d-d thread, and would have meant pretty much blocking progress on this issue for longer, and it also really seems tangential to the topic of dropping the field. For example, we have also briefly discussed the latter on IRC today, and there were differing opinions on how and why to implement this dirty/clean tracking. Helmut was in favor of having some tracking, but Josch and me agree that encoding this on each and every package is not ideal, as this duplicates information all over the place, instead of say having a central registry denoting what is dirty/clean, and it is also prone to get out of sync with the profiles supported by the package. One problem with a central registry that Helmut brought up was the private «pkg.» namespace, but then Josch mentioned that in that case we could encode the information in the same namespace like «pkg-dirty.*». So you see, while there was fast consensus before the upload on dropping the field, there are still probably many open questions regarding the dirty/clean topic. Hope that clarifies. Thanks, Guillem
