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? :) Thanks, Guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140320060010.ga2...@gaara.hadrons.org
