On Friday 23 February 2007 06:18, Ciaran McCreesh wrote: > On Thu, 22 Feb 2007 22:05:56 +0100 Thomas de Grenier de Latour > > <[EMAIL PROTECTED]> wrote: > | On Thu, 22 Feb 2007 19:08:48 +0000, Ciaran McCreesh > | > | <[EMAIL PROTECTED]> wrote: > | > As has been discussed in the past, the only correct way of handling > | > this from an ebuild perspective is lots of use && has_version calls > | > | Which sounds like trying to mimic whatever the deps solver logic may > | have been, no? So, why not just let the dep solver itself give the > | right answer to the ebuild? It could well set a resolved DEPEND > | variable (lets call it $RESOLVED_DEPEND for instance) in the ebuild > | env, that one could query with some helper functions.
This is the best solution that I could come up with in the past as well. > That strikes me as another large complication. Something that > complicated shouldn't be necessary. > > Also, I'd like an EAPI-0-able solution :) Disallowing it would be the cleaner in terms of package manager responsibilities, but ... > | > So, is there a legitimate reason for this complication to exist? Or > | > should use? blocks being direct children of || ( ) be forbidden? > | > | It's not clear to me what would be your prefered DEPEND syntax for the > | ebuild(5) example you've quoted. Something like this maybe?: > | sdl? ( media-libs/libsdl ) > | !sdl? ( > | svga? ( media-libs/svgalib ) > | !svga? ( > | ... > | > | (which is not really equivalent) > > Right. It's not the same, but it's a lot more logical. the above code - while likely to be what the ebuild author was originally intending when using the "|| ( use? () )" - is not very readable or maintainable. There's also one other issue that you didn't mention in your original email. If an ebuild has "|| ( foo? ( foo/pkg ) bar? ( bar/pkg ) )" and neither foo or bar are set, should it be an error because there was no successful result among the possibilities? While my gut feeling says "yes" and (I think) portage currently says "no", I can't really see any strong reason for either case. Disallowing use clauses directly beneath || constructs would completely sidestep that issue too. ;) But I still what TGL described even if only for EAPI-1 or beyond... -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
