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

[Johannes Schauer <j.schauer@email.de>]

Hi Guillem,

Quoting Guillem Jover (2014-03-20 07:00:10)
> 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.

you are right.

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

No, the fact that this information is not propagated into the Packages or
Sources files either has actually been an issue. Even when only theoretically
calculating the bootstrapping order.

What we did so far, for the theoretical analysis of an imaginary new
architecture "foo64" was to add that architecture to all Architecture fields in
a Sources file which were not any/all. We then took, say, the amd64 Packages
file and did something along the lines of s/amd64/foo64/.

So yes, you are right, it is a problem that this information is not propagated
from the debian/control file either and it has to be fixed *somehow* as well.

> 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? :)

Yes, sorry, it seems I was talking past you in my last email but I think I
understand your point now. Your analogy between the Architecture and the
Build-Profiles field makes perfect sense now.  Yes, for bootstrapping purposes
it would also be required to have knowledge about the content of the
Architecture field in the debian/control binary stanzas. I actually completely
forgot about the hack that we used so far to get around this limitation for the
theoretical analysis. Probably because the past year we were focused on
bootstrapping existing architectures like armhf.

So maybe this brings us back to encoding the Architecture as well as the
Build-Profiles field information in the Package-List field of the source
package as suggested by Raphaël Hertzog?

Or maybe two new fields would solve the problem along the lines of
Builds-With-Architecture and Builds-With-Build-Profiles?

Any other options?

Thanks a lot for reminding me of the problem with the Architecture field and
being patient with me :)

cheers, josch