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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/20140317234045.1302.90338@hoothoot
