Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 143908 - || ( a b ) in DEPEND with 'a' p.masked causes portage to "die" saying 'a' is masked
Summary: || ( a b ) in DEPEND with 'a' p.masked causes portage to "die" saying 'a' is ...
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Dependencies (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
: 136311 143921 147108 (view as bug list)
Depends on:
Blocks: 155723 136244
  Show dependency tree
 
Reported: 2006-08-14 11:21 UTC by Andrew Gaffney (RETIRED)
Modified: 2006-11-19 15:01 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Rewrite of || () handling in dep_zapdeps (ordeps-rewrite.patch,3.65 KB, patch)
2006-08-16 07:31 UTC, Jason Stubbs (RETIRED)
Details | Diff
Same but doesn't downgrade (ordeps-rewrite-nodowngrade.patch,4.40 KB, patch)
2006-08-16 07:49 UTC, Jason Stubbs (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Gaffney (RETIRED) gentoo-dev 2006-08-14 11:21:20 UTC
!!! 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])
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2006-08-14 13:28:49 UTC
*** Bug 143921 has been marked as a duplicate of this bug. ***
Comment 2 Zac Medico gentoo-dev 2006-08-14 14:30:48 UTC
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.
Comment 3 Harald van Dijk (RETIRED) gentoo-dev 2006-08-16 03:52:16 UTC
(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.
Comment 4 Harald van Dijk (RETIRED) gentoo-dev 2006-08-16 03:52:51 UTC
Probably better to reopen too, then :)
Comment 5 Jason Stubbs (RETIRED) gentoo-dev 2006-08-16 07:31:57 UTC
Created attachment 94397 [details, diff]
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?
Comment 6 Jason Stubbs (RETIRED) gentoo-dev 2006-08-16 07:49:51 UTC
Created attachment 94398 [details, diff]
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.
Comment 7 Alec Warner archtester Gentoo Infrastructure gentoo-dev Security 2006-08-16 09:31:48 UTC
(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.
Comment 8 Zac Medico gentoo-dev 2006-08-16 19:07:37 UTC
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.
Comment 9 Zac Medico gentoo-dev 2006-08-17 00:14:47 UTC
This has been released in 2.1.1_pre5-r2.
Comment 10 Jakub Moc (RETIRED) gentoo-dev 2006-08-25 15:25:41 UTC
*** Bug 136311 has been marked as a duplicate of this bug. ***
Comment 11 Jakub Moc (RETIRED) gentoo-dev 2006-09-10 15:08:44 UTC
*** Bug 147108 has been marked as a duplicate of this bug. ***