On 08/31/2012 02:53 PM, Ciaran McCreesh wrote: > On Fri, 31 Aug 2012 14:11:38 -0700 > Zac Medico <zmed...@gentoo.org> wrote: >> On 08/31/2012 01:46 PM, Ciaran McCreesh wrote: >>> On Fri, 31 Aug 2012 13:03:00 -0700 >>> What exactly would the rules be for handling a package that is in >>> both DEPEND and HDEPEND, when ROOT is in effect? Would the versions >>> be expected to match? What about use flags? >> >> For the sake of simplicity, I would treat them as entirely >> independent. It should be easy enough for users to apply manual >> configuration adjustments in order to resolve any conflicts of this >> nature that may arise. If there turns out to be a strong demand for >> additional constraints, we can consider adding them in a future EAPI >> (possibly using a combined DEPENDENCIES variable). > > The thing is... Without some kind of "the same" constraint, we'd be > adding a feature which would probably work most of the time only by > coincidence.
Shrug, I don't do any cross-compilation myself, but maybe someone who does could comment on the usefulness of this kind of constraint. Mike? Brian? >>> Also, we're getting rather a lot of *DEPEND variables here... If >>> we're making people make major changes to their deps, which for >>> HDEPEND we definitely would be, >> >> Well, I not sure that "major changes" is a really good >> characterization. We're just talking about migrating a few things >> from DEPEND to HDEPEND, and it's not strictly required. The migration >> is only needed when fulfilling a request to support cross-compilation >> in a particular ebuild. > > Where are you getting "a few" from? Is this "a few seems to be enough > to make it work", or "someone carefully analysed lots of packages to > work out exactly what dependencies are HDEPEND, and measured it"? I > strongly suspect we're in "works by coincidence" territory again -- > "adding packages to HDEPEND as breakages are encountered" is a long way > from "having an accurate HDEPEND". Are we aiming for the former or the > latter? I would think of it like prefix support in EAPI 3. Ebuilds using EAPI 3 were not required to support prefix. Similarly, ebuilds using EAPI 5 will not be required to support cross-compilation. -- Thanks, Zac
