Re: propagating the value of the build-profiles field to Packages and Sources files
Hi,
Quoting Guillem Jover (2014-03-14 20:46:23)
> > Right now the information which binary packages do or do not build for
> > which build profile is restricted to debian/control. Coming back to my
> > original mail: what do you see as the best way to propagate this
> > information into the Packages/Sources files?
>
> Well, let's backtrack a bit, how do you currently handle the
> Architecture field in the binary package stanzas in debian/control
> restricting the set of produced packages? Because at the end it's
> exactly the same issue, and we currently do not propagate that in a
> detailed way further on (the Architecture field in .dsc is pretty
> broad). It seems you'd need both of those propagated, and it starts to
> feel a bit icky somehow.
The Architecture field changes its meaning depending where it is used. In
debian/control binary stanzas it means "can be built on these architectures"
and in a Packages file it means "the binary package was built for this
architecture". The former allows multiple values or wildcards while the latter
does not. The information which binary package can be built on what
architecture can be reconstructed from consulting multiple Packages files (one
per architecture). So the value of the Architecture field in debian/control is
somewhat propagated into or spread over multiple Packages files.
The latter does not work with build profiles because binaries with build
profiles are not supposed to be uploaded into a package archive. So if we
construct the Build-Profiles field as having a similar changing meaning as the
Architecture field, then it would mean that it changes from indicating for
which profile a binary package builds in debian/control to indicating for what
profile a binary package was built in a Packages file. But as binaries built
with a profile will not make it into any other archives then the one of the
bootstrapper this does not help.
So maybe this means to give up trying to make the Build-Profiles field work
very similar to how the Architecture field works? For example one solution
might be to let the Build-Profiles field *not* change its meaning between its
usage in debian/control and in a Packages file (or in DEBIAN/control). In all
these places it would mean "this binary package builds with the following
profiles". The information with which profile(s) a binary package was built can
be encoded in another field and currently the field Built-For-Profiles is used
for that.
I think this is what the diff in my first email in this thread implements.
Maybe this is not the right way to do things but if so, then I dont think I can
come up with a more *proper* way to handle this because I lack the experience
of a dpkg maintainer :)
What do you think?
cheers, josch
Reply to: