[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 Tue, 2014-03-18 at 00:40:45 +0100, Johannes Schauer wrote:
> 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.

Sorry, what I meant is that the information of which architecture each
binary package is built on is only propagated to the Packages files if
those binaries have been built before, which is usually not the case
when bootstrapping a new architecture, so one cannot make use of those
indices to infer that information.

Perhaps the architecture restrictions have just not been an issue when
calculating the bootstrapping order, though?

My point was that, because there's (supposedly) no previously built
packages, this information cannot be inferred from them for either
the Architecture or Build-Profiles fields. And the only reliable
source is the debian/control file.

> What do you think?

I'm not sure if we are talking past each other? :)


Reply to: