| Summary: | || ( a b ) in DEPEND with 'a' p.masked causes portage to "die" saying 'a' is masked | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Andrew Gaffney (RETIRED) <agaffney> |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gentoo-bugzilla, ikelos, jaak, jakub, slucy, truedfx |
| Priority: | High | Keywords: | InVCS |
| Version: | 2.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 155723, 136244 | ||
| Attachments: |
Rewrite of || () handling in dep_zapdeps
Same but doesn't downgrade |
||
|
Description
Andrew Gaffney (RETIRED)
2006-08-14 11:21:20 UTC
*** 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 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?
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.
(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. *** |
