Bugzilla Bug 143908

!!! All ebuilds that could satisfy "app-admin/eselect-compiler" have been
masked.
!!! One of the following masked packages is required to complete your request:
- app-admin/eselect-compiler-2.0.0_rc1-r6 (masked by: package.mask)
# Ned Ludd <solar/gentoo.org> (Aug 14 2006)
# This this breaks working systems and eradicator
# has gone MIA yet again. Bug 137917

- app-admin/eselect-compiler-2.0.0_rc2 (masked by: package.mask)
- app-admin/eselect-compiler-2.0.0_rc2-r1 (masked by: package.mask)

For more information, see MASKED PACKAGES section in the emerge man page or
refer to the Gentoo Handbook.
(dependency required by "sys-libs/glibc-2.4-r3" [ebuild])

*** Bug 143921 has been marked as a duplicate of this bug. ***

The problem seems to be that gcc-config-2.0.0_rc1 also needs to be masked in
order to prevent eselect-compliler from being selected as a candidate. 
Intially, eselect-compiler was masked, but gcc-config-2.0.0_rc1 was still
unmasked as shown here:

http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/package.mask?r1=1.5735&r2=1.5736

Portage's resolver needs hints in order to make the correct choices.  Once it
starts down the wrong path, it's unable to backtrack.  A more robust resolver
is certainly needed, but it is not a small undertaking.

(In reply to comment #2)
> The problem seems to be that gcc-config-2.0.0_rc1 also needs to be masked in
> order to prevent eselect-compliler from being selected as a candidate. 
> Intially, eselect-compiler was masked, but gcc-config-2.0.0_rc1 was still
> unmasked as shown here:

Sorry, but that's only one of the reasons you can get this error, and the other
is not fixed. I can still get the original error message, and an extremely
simple test shows this:

$ emerge -pv testa testb

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] test/testa-1.0  0 kB [1] 
[ebuild   R   ] test/testb-1.0  0 kB [1] 

Total size of downloads: 0 kB
Portage overlays:
 [1] /etc/portage/overlay
 [2] /etc/portage/overlay/enlightenment
$ cd /etc/portage/overlay
$ cat test/testa/testa-1.0.ebuild
KEYWORDS="~x86"
$ cat test/testb/testb-1.0.ebuild
KEYWORDS="~x86"
DEPEND="|| ( test/testa sys-apps/portage )"
$ echo test/testa >>/etc/portage/package.mask
$ emerge -pDuv test/testb

These are the packages that would be merged, in order:

Calculating dependencies -
!!! All ebuilds that could satisfy "test/testa" have been masked.
!!! One of the following masked packages is required to complete your request:
- test/testa-1.0 (masked by: package.mask)

For more information, see MASKED PACKAGES section in the emerge man page or 
refer to the Gentoo Handbook.
(dependency required by "test/testb-1.0" [ebuild])

In other words, portage continues to prefer test/testa since it's installed
already, even though it's now hardmasked.

Probably better to reopen too, then :)

Created an attachment (id=94397) [edit]
Rewrite of || () handling in dep_zapdeps

I went to try and fix this bug but couldn't figure out what was going on in
that function (and I wrote that code!) so I rewrote it to be a bit more
readable and added comments as well.

I do know what the previous code was written to do though and this patch
changes it slightly. One change of course is that the availablity of masked
packages is checked, fixing this bug. The other change however...

I'm sure everybody knows of kde's DEPEND="|| ( =qt-3.3* =qt-3.2* =qt-3.1* )".
Yep, versions are different and correct atoms are used, but that's the spirit.
Previous to the unintelligable code that is now in dep_zapdeps the above DEPEND
wouldn't upgrade qt-3.1 if it was installed. The current code will look for the
atom that matches the highest version that shares the key of an installed
package.

This patch however will just choose the first atom that shares the key of an
installed package. Hence if there are any constructs such as "|| ( =qt-3.2*
=qt-3.3* =qt-3.1* )", it will actually cause qt-3.3 to be downgraded to qt-3.2
when --upgrade is specified. So the question is whether this is preferred
behaviour or whether a check should be put in to circumvent it?

Created an attachment (id=94398) [edit]
Same but doesn't downgrade

Partially addresses the behaviour change stated in my last comment. The
behaviour with this patch would be:

DEPEND="|| ( some-pkg =qt-3.2* =qt-3.3* =qt-3.1* )"
qt-3.1 installed? Choose qt-3.2
qt-3.2 installed? Choose qt-3.2
qt-3.3 installed? Choose qt-3.3
None installed? Choose some-pkg

Current behaviour would be to choose qt-3.3 in all cases but the last.
Behaviour of the last patch would be to choose qt-3.2 in all cases but the
last.

(In reply to comment #5)
> Created an attachment (id=94397) [edit]
> Rewrite of || () handling in dep_zapdeps
> 
> I went to try and fix this bug but couldn't figure out what was going on in
> that function (and I wrote that code!) so I rewrote it to be a bit more
> readable and added comments as well.
> 
> I do know what the previous code was written to do though and this patch
> changes it slightly. One change of course is that the availablity of masked
> packages is checked, fixing this bug. The other change however...
> 
> I'm sure everybody knows of kde's DEPEND="|| ( =qt-3.3* =qt-3.2* =qt-3.1* )".
> Yep, versions are different and correct atoms are used, but that's the spirit.
> Previous to the unintelligable code that is now in dep_zapdeps the above DEPEND
> wouldn't upgrade qt-3.1 if it was installed. The current code will look for the
> atom that matches the highest version that shares the key of an installed
> package.
> 
> This patch however will just choose the first atom that shares the key of an
> installed package. Hence if there are any constructs such as "|| ( =qt-3.2*
> =qt-3.3* =qt-3.1* )", it will actually cause qt-3.3 to be downgraded to qt-3.2
> when --upgrade is specified. So the question is whether this is preferred
> behaviour or whether a check should be put in to circumvent it?
> 

IMHO thats proper, the point of || deps is "find the first available working
dep", if as an ebuild developer you want the highest dep to be the first
selected, then put it first.

I've committed the second patch in svn r4271.  Technically, || deps should be
satisfied by any one of the choices.  Thus, I think it's good do avoid a
downgrade if it can be done while keeping the dep satisfied.

This has been released in 2.1.1_pre5-r2.

*** Bug 136311 has been marked as a duplicate of this bug. ***

*** Bug 147108 has been marked as a duplicate of this bug. ***