Hi! On Fri, 2014-02-21 at 12:30:13 +0100, Johannes Schauer wrote: > The problem is, that tools which analyze dependency relationships between > binary and source packages (like dose3), currently use only Packages and > Sources files as input. While the <!profile.stage1> bits of the Build-Depends > field is properly propagated into the Sources file, the information which > binary packages do or do not build with one or more profiles activated (the > content of the Build-Profiles field in the binary package stanzas in > debian/control) is currently not included in either the Packages or the > Sources > file. Therefore, currently, a tool like dose3 would have to have access to > the > debian/control files of all relevant (since there is no way to know > beforehand, > this would probably mean *all*) source packages to get this information.
Ok, just to clarify what we are talking about, and which recently realized (after having seen the debhelper implementation) I might have misunderstood the proposed purpose of the field in the past, and think I might have already said I was not convinced about due to that, and the reason I ignored it for now in the current dpkg implementation. Here the Build-Profiles field in a binary package stanza, would denote (in a declarative way) if the binary package will get _produced_ or not depending on the build profile restrictions; and *not* denote a list of profiles supported by that binary package (or profiles that binary can be built with), which has the problem of making it difficult to keep up to date or being exhaustive, which is what I remember from the previous descriptions of the field? Thanks, Guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140307021854.ga22...@gaara.hadrons.org
