Reason: almost every usage of it in the tree is wrong and breaks dependencies, resp. doesn't do what the user expects being done. Quoting ciaranm here: Let's say you have the following: DEPEND="|| ( foo? ( cat/foo ) bar? ( cat/bar ) cat/baz )" Then this is wrong: if use foo ; then myconf="--enable-foo" elif use bar ; then myconf="--enable-bar" else myconf="--enable-baz fi Here's why: Say the user already has baz installed, and has USE="foo". The package manager will see that baz is already installed, and as per the rules for || will not look at the foo or bar deps. So if the user doesn't have foo installed, the --enable-foo will be wrong. So the 'correct' code would have to be something like this: if use foo && has_version cat/foo ; then myconf="--enable-foo" elif use bar && has_version cat/bar ; then myconf="--enable-bar" else myconf="--enable-baz fi Except this is *still* a mess, because a user who has USE="foo bar" is going to end up with a differently configured package depending upon what he happens to have installed up-front, which is something that's not supposed to happen.
So what is the proposed alternative? Are we sure this is the only use case for "|| ( foo? ( . ) . )"?
(In reply to comment #1) > So what is the proposed alternative? > Are we sure this is the only use case for "|| ( foo? ( . ) . )"? The alternative is to write your deps out correctly. There is no way to use this construct correctly.
Do I understand it correctly, the construct is equivalent to the following? DEPEND=" foo? ( bar? ( || ( cat/foo cat/bar cat/baz ) ) !bar? ( || ( cat/foo cat/baz ) ) ) !foo? ( bar? ( || ( cat/bar cat/baz ) ) !bar? ( cat/baz ) )"
(In reply to comment #3) > Do I understand it correctly, the construct is equivalent to the following? Uh, that looks right, yes. Of course, it's almost certainly not what anyone wants to write...
do any packages in the tree today actually use this construct?
(In reply to Alex Xu (Hello71) from comment #5) > do any packages in the tree today actually use this construct? Yes, and in a legitimate way.
Legitimately? Really? Examples please. Remember that any example that actually checks the use flag that's present inside the || block is not legitimate.
grep -rE '^DEPEND=.*\|\| \( [^ []*\?' /usr/portage/metadata/md5-cache/ this only shows uses where the use-conditional is first in the || block, since it is not possible to do a perfect check using pure regex. however, on my tree, it only shows: media-sound/pulseaudio-*:DEPEND=|| ( elibc_glibc? ( virtual/libc ) elibc_uclibc? ( virtual/libc ) dev-libs/libpcre ) ... which seems legitimate, since only one elibc can be set, and all packages must be rebuilt if elibc is changed.
(In reply to Alex Xu (Hello71) from comment #8) > grep -rE '^DEPEND=.*\|\| \( [^ []*\?' /usr/portage/metadata/md5-cache/ > > this only shows uses where the use-conditional is first in the || block, > since it is not possible to do a perfect check using pure regex. > > however, on my tree, it only shows: > > media-sound/pulseaudio-*:DEPEND=|| ( elibc_glibc? ( virtual/libc ) > elibc_uclibc? ( virtual/libc ) dev-libs/libpcre ) ... > > which seems legitimate, since only one elibc can be set, and all packages > must be rebuilt if elibc is changed. This is a good example of an incorrect dependency...
virtual/linux-sources used to have the following which I believe was correct: RDEPEND="|| ( hardened? ( =sys-kernel/hardened-sources-3* ) xrc? ( =sys-kernel/cluster-sources-3* ) =sys-kernel/gentoo-sources-3* =sys-kernel/vanilla-sources-3* ... )"
(In reply to Ulrich Müller from comment #10) > virtual/linux-sources used to have the following which I believe was correct: > > RDEPEND="|| ( > hardened? ( =sys-kernel/hardened-sources-3* ) > xrc? ( =sys-kernel/cluster-sources-3* ) > =sys-kernel/gentoo-sources-3* > =sys-kernel/vanilla-sources-3* > ... > )" Those flags are just superfluous.
you want a more complete grep like: grep -rE 'DEPEND=.*\|\|[[:space:]]+[(][^)]*[?][[:space:]]+[(]' \ /usr/portage/metadata/md5-cache/ the pulseaudio dep looks like it should be written as: !elibc_glibc? ( !elibc_uclibc? ( dev-libs/libpcre ) ) the virtual/kernel examples seem like the USE flags are superfluous. even when they're doing it based on KEYWORD availability of the target. other examples: games-strategy/dominions2 & games-strategy/heroes3-demo & games-fps/unreal-tournament-goty & app-emulation/crossover-bin do something like: RDEPEND=" || ( ppc? ( media-libs/libsdl virtual/opengl virtual/glu ) !ppc? ( media-libs/libsdl[abi_x86_32(-)] virtual/opengl[abi_x86_32(-)] virtual/glu[abi_x86_32(-)] ) )" that doesn't seem wrong to me as it's a binary package. would be nice if it could be written differently. net-print/hplip seems legit: hpijs? ( || ( >=net-print/cups-filters-1.0.43-r1[foomatic] >=net-print/foomatic-filters-3.0.20080507[cups] ) ) as does the portage one: || ( >=dev-lang/python-2.7[ssl] dev-lang/python:2.6[threads,ssl] )
