[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: propagating the value of the build-profiles field to Packages and Sources files


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

> 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.


Reply to: