Hey! On Fri, 2014-03-07 at 15:57:53 +0100, Johannes Schauer wrote: > Quoting Guillem Jover (2014-03-07 03:18:54) > > 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?
> I find myself having trouble parsing the last two sentences, so let me make > sure we are talking about the same thing and not past each other. > > The problem might lie in the fact that I do not understand how "profiles the > binary package gets produced for" is different from "profiles the binary > package supports or can be built with". Ok, two scenarios. First one, you have a source producing multiple binary packages, one of which contains only an ldap plugin. If the package honours a build profile that restricts on ldap then that package would not get produced at all, this is the common case you find in a bootstrapping scenario for example. The second one, would be a source package that produces for example a foo-plugins binary package containing say ldap and mysql plugins, and if a restriction on ldap is requested then that binary will end up only containing the mysql plugin, so that package supports and can be built with such profile. > In the spec [1] it says: "In debian/control binary package stanzas, the > content > of the Build-Profiles field specifies the (unordered) list of build profiles > for which that binary package does or does not build.". So if a package in > debian/control says: > > Build-Profiles: stage1 > > then that binary package would only build when stage1 is active. If it says: > > Build-Profiles: !stage1 > > then that binary package would build in all cases except when stage1 is > active. > This is what debhelper recently implemented. Yeah, this is clearer now, I seem to remember a different wording when I saw this initially, probably in the mailing list, but I might be misremembering. I still wanted to make sure. > Do you find this problematic? Not really, it matches the Architecture field, in that it describes in a descriptive way when the package should be produced or not. And I find this makes more sense than what I had understood initially. But this ties with the desire to know when those build profiles apply from the Sources/Packages files, which applies to the two scenarios described above. Hope that clarifies, otherwise I can try to expand further on. 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/20140307213415.ga5...@gaara.hadrons.org
