Re: propagating the value of the build-profiles field to Packages and Sources files
Hi Guillem,
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".
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. Do you find this problematic?
I'm sorry that I'm having trouble understanding your last email. Hopefully your
next email will make things clear for me.
cheers, josch
[1] https://wiki.debian.org/BuildProfileSpec
Reply to: