I don't want to duplicate everything that has already been discussed on irc, so I just paste the log below. The reason for this question coming up was that with the new use deps built_with_use + die could be avoided. So I thought probably this also possible for the case when at least one/more/all flags from a set of use flags have to be enabled for the package to work properly. With a functionality like this another case of unnecessary abortion of the build process could be removed. <billie> is it possible to avid the following with the new use deps? <billie> if ! use flag1 && ! use flag2 ; then eerror "build at least with flag1 or flag2" die "both flags are unset" fi <Arfrever> billie: No. <billie> Arfrever: thanks <Arfrever> billie: Use dependencies check if USE flags are enabled/disabled in other packages, not in package currently being installed. <Betelgeuse> billie: That would be an extension to IUSE syntax. <Betelgeuse> billie: IUSE="|| ( flag1 flag2 )" <Betelgeuse> billie: file a reuest <Caster> makes no sense <tanderson> ah...paludis is going to do that with annotations iirc <Betelgeuse> Caster: Yeah selecting a default and makingthe other a use flag makes moresense <Betelgeuse> Damn space is getting old. <Caster> tanderson: annotations sounds like something optional <billie> but what if you hava a client server app <billie> one would build the server and one the client <tanderson> Caster: well, it'd be like this: IUSE=" server [[ require = client ]]" <billie> so a default also does not make much sense <Caster> I'm not sure about overloading IUSE <Caster> that much <Caster> maybe add something as IUSE_RESTRICT="" <Caster> could set both stuff like "one of these must be enabled" or "flag1 and flag2 can't be both enabled" <tanderson> well, you could use pkg_pretend and an eclass to do it <Caster> except there's no pkg_pretend :) <solar> :) <tanderson> I know :( <tanderson> I'm just saying how it could be solved <zmedico> syntax would be better though <zmedico> spawning bash for that is a waste of resources
http://lists.exherbo.org/pipermail/exherbo-dev/2008-August/000241.html http://lists.exherbo.org/pipermail/exherbo-dev/2008-September/000293.html These threads may be of use. In particular note the list of use cases, and how they don't map nicely onto || or any existing construct.
Could it potentially be expressed in a syntax similar to the USE depends syntax? IUSE="flag1[flag2]" # if flag1 is set, requires flag2 to be set. IUSE="flag1[-flag2]" # if flag1 is set, requires flag2 not to be set. IUSE="flag1[flag2,flag3" # if flag1 is set, requires flag2 and flag3 to be set. IUSE="flag1[-flag2,flag3]" # if flag1 is set, requires flag2 not to be set and flag3 to be set. IUSE="-flag1[-flag2]" # if flag1, isn't set, requires flag2 not to be set
How would you express the common use cases discussed in the threads I linked to using those formats?
FWIW, with EAPI 2 use deps, it's possible to express at least some cases of what's being requested here. This can be accomplished by making a package have a circular RDEPEND use-dep on itself.
(In reply to comment #4) > FWIW, with EAPI 2 use deps, it's possible to express at least some cases of > what's being requested here. This can be accomplished by making a package have > a circular RDEPEND use-dep on itself. > And to prevent two different versions of the same package from being pulled together, one can use use1? ( =this-cat/${PF}[use2] ) assuming that =pkg-1.0-r0 will properly match =pkg-1.0 as well
(In reply to comment #5) > And to prevent two different versions of the same package from being pulled > together, one can use > > use1? ( =this-cat/${PF}[use2] ) > > assuming that =pkg-1.0-r0 will properly match =pkg-1.0 as well A clarification: one way in which two different versions of the same package can be pulled-in is due to version-specific EAPI=1 +use IUSE enabling. However, this will probably be a non-issue once automatic-use-deps are done.
Uhm. No you can't. This means you need the package already installed with a particular flag in order to install it. It has a whole different meaning, and relying upon bugs in how Portage handles it is a very bad idea.
*** Bug 300020 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 347353 ***