| Summary: | New portage handles ||() incorrectly ? (defaults to masked modular xorg instead of monolithic xorg) | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Fred Krogh <fkrogh> |
| Component: | Core - Dependencies | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | cslycord, gent_bz |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Result of running emerge --debug -Dau world with portage-2.0.54
Result of running emerge --debug -Dau world with portage-2.1_pre5-r1 My /var/lib/portage/world |
||
|
Description
Fred Krogh
2006-01-29 08:39:22 UTC
Kindly review the following before reporting portage "bugs" http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=3#doc_chap3 I'm sorry, but I don't see why the previous comment. I have neither portage nor X11 unmasked. Portage is masked as if I try to use it, it leads to problems. I truly would like to help by reporting bugs, but at the moment I have no ides why this should not have been reported. yeah, settle down, the new portage 2.1_pre4 appears to handle || () incorrectly Note that in my original comment, I mentioned that portage 2.1_pre4 was still causing the problem for me. (That was pre4-r1 so maybe an r2 is on the way?) Cannot reproduce this - a simple test: gcc has the following deps, so the bug should manifest itself, right? || ( app-admin/eselect-compiler >=sys-devel/gcc-config-1.3.12-r4 ) # emerge -pv eselect-compiler These are the packages that I would merge, in order: Calculating dependencies !!! All ebuilds that could satisfy "eselect-compiler" have been masked. !!! One of the following masked packages is required to complete your request: - app-admin/eselect-compiler-2.0.0_beta5 (masked by: package.mask, ~x86 keyword) # Jeremy Huddleston <eradicator@gentoo.org> (24 Sep 2005) # Still in development - app-admin/eselect-compiler-2.0.0_rc1-r1 (masked by: package.mask, ~x86 keyword) For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. # emerge -pv gcc-config These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] sys-devel/gcc-config-1.3.12-r6 0 kB # emerge -uDpv world These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild N ] sys-devel/gcc-config-1.3.12-r6 0 kB I think I'm seeing something related to this - although it may not be related. I have xorg-7 (many packages unmasked in package.unmask) and portage 2.1_pre4-r1. emerge -pv Xaw3d These are the packages that I would merge, in order: Calculating dependencies ...done! [blocks B ] x11-libs/libXft (is blocking x11-base/xorg-x11-6.8.99.15-r4) [ebuild N ] x11-base/opengl-update-3.0.0 0 kB [ebuild UD] x11-base/xorg-x11-6.8.99.15-r4 [7.0-r1] USE="bitmap-fonts% doc% ipv6% nls% opengl% pam% truetype-fonts% type1-fonts% xv% -3dfx -cjk% -debug% -font-server% -insecure-drivers% -minimal% -nocxx% -sdk% -static% -xprint" 0 kB [ebuild N ] virtual/x11-6.8 0 kB [ebuild N ] x11-libs/Xaw3d-1.5-r1 0 kB Total size of downloads: 0 kB It *appears* that emerge is making the wrong choice wrt xorg-x11 versions. Running emerge with --debug includes this output : Depstring: || ( ( x11-libs/libXt x11-libs/libX11 x11-libs/libXmu x11-libs/libXpm x11-libs/libXp ) virtual/x11 ) >=sys-apps/sed-4 || ( ( x11-proto/xextproto x11-misc/imake x11-misc/gccmakedep ) virtual/x11 ) !bootstrap? ( sys-devel/patch ) || ( ( x11-libs/libXt x11-libs/libX11 x11-libs/libXmu x11-libs/libXpm x11-libs/libXp ) virtual/x11 ) Candidates: ['virtual/x11'] Manually emerging all the would-be xorg-7 dependencies gives the following (making it clear as to what is going on) : emerge -pv libXt libX11 libXmu libXpm libXp xextproto imake gccmakedep These are the packages that I would merge, in order: Calculating dependencies - !!! All ebuilds that could satisfy "gccmakedep" have been masked. !!! One of the following masked packages is required to complete your request: - x11-misc/gccmakedep-1.0.1-r1 (masked by: package.mask) # Donnie Berkholz <spyderous@gentoo.org> (07 Aug 2005) # Modularized X, upstream release candidates So the "problem" was actually that one dep was still masked, because gccmakedep has been recently added to package.mask. Adding gccmakedep to my package.unmask results in the 'correct' set of deps being calculated. There's a bunch of Xaw3d related bugs (that have been closed by Jakub) that could *probably* be solved with a closer examination of package.*mask - in fact, I suspect that any package that depends on gccmakedep will be seeing some emerge-gives-wrong-deps type bugs. The problem is quite a subtle one - a little more diagnostic info from emerge would be really handy in cases like this. *** Bug 124032 has been marked as a duplicate of this bug. *** I just installed sys-apps/portage-2.1_pre5-r1, and after the emerge, an emerge -Dau world, still gives !!! All ebuilds that could satisfy "x11-libs/libX11" have been masked. !!! One of the following masked packages is required to complete your request: - x11-libs/libX11-1.0.0-r2 (masked by: package.mask) # Donnie Berkholz <spyderous@gentoo.org> (07 Aug 2005) # Modularized X, upstream release candidates So at least for me this latest portage still has the same problem. What output do you get with 'emerge --debug -Dua' ? (In reply to comment #9) > What output do you get with 'emerge --debug -Dua' ? > I mainly just get a question asking me what I want to do. If I add "world" at the end, I get lots of output. Before attaching that, I'd like to know exactly what you want including whether it should be done with the portage-2.0.54 that I'm using now, or you want it with the new portage that fails. And whether you want "world" at the end. Thanks. (In reply to comment #10) > (In reply to comment #9) > > What output do you get with 'emerge --debug -Dua' ? > > > > I mainly just get a question asking me what I want to do. If I add "world" at > the end, I get lots of output. Before attaching that, I'd like to know exactly > what you want Hopefully, amongst it there will be information that may help diagnose the problem. > including whether it should be done with the portage-2.0.54 that > I'm using now, or you want it with the new portage that fails. Both would probably be useful... > And whether you want "world" at the end. Yes, sorry. Created attachment 80795 [details]
Result of running emerge --debug -Dau world with portage-2.0.54
Created attachment 80796 [details]
Result of running emerge --debug -Dau world with portage-2.1_pre5-r1
What output from "emerge -pv virtual/x11"? (In reply to comment #14) > What output from "emerge -pv virtual/x11"? > Both versions give the same output, namely, These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] virtual/x11-6.8 0 kB Total size of downloads: 0 kB It would indeed appear to be a portage bug, but I cannot reproduce it here. Specifically, something appears to be screwy in the process of calculating deps for tk. You could try 'emerge -pv tk' (or 'emerge -pv gcc tk' on a whim) and see if that demonstrates the bug, otherwise I'm out of ideas. Well, you could post your world file (/var/lib/portage/world). That /may/ be of interest... Created attachment 80799 [details]
My /var/lib/portage/world
And here are other results requested (for the working portage only)
emerge -pv tk
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] dev-lang/tk-8.4.11-r1 +threads 0 kB
Total size of downloads: 0 kB
=================== and
emerge -pv gcc tk
These are the packages that I would merge, in order:
Calculating dependencies ...done!
[ebuild R ] sys-devel/gcc-3.4.5 (-altivec) -bootstrap -boundschecking -build +fortran -gcj +gtk -hardened -ip28 (-multilib) -multislot (-n32) (-n64) +nls -nocxx -nopie -nossp -objc -vanilla 47 kB
[ebuild R ] dev-lang/tk-8.4.11-r1 +threads 0 kB
Total size of downloads: 47 kB
I've tried a few more things and I just cannot reproduce this bug. Final idea : upgrade to latest portage, run 'emerge --metadata' and 'emerge -Dua world' again. (In reply to comment #18) > I've tried a few more things and I just cannot reproduce this bug. > > Final idea : upgrade to latest portage, run 'emerge --metadata' and 'emerge > -Dua world' again. > Sorry this is final. I've tried this, and I'm having the same old problem. Thanks. The bug isn't with portage, it's with the visibility of the packages in question- reread comment #6, it's dead on. reassigning... (In reply to comment #20) > reread comment #6, it's dead on. reassigning... Err, thanks. But (just to be clear) comment #6 is not the original bug - just something that (I thought) looks like it. What is the exact problem in this case? And what is the difference between 2.0.54 and 2.1_pre that is causing it to happen? The only times I've been seeing this fail is when the masked package happens to be installed already (but wasn't in the world file as it had been a dependency of something else I installed during the time I had stuff unmasked). Like when you have || ( x11-libs/libX11 virtual/x11 ) and libX11 installed (but not in world file) things get messed up. Now one wonders why portage doesn't just (by default) search /var/db/pkg for packages installed that are masked rather than have it done in an obscure dependency sorter? (In reply to comment #21) > And what is the difference between 2.0.54 and 2.1_pre that is causing it to > happen? For ||() parsing, 2.1 has a subtle bug corrected- || ( a ( b? ( c ) ) ) b is False || ( a ( ) ) Portage would use the empty node, '()' to satisfy the or. It's possible it's what's occuring here, but I would dig down through the emerge -Dd output and verify it. Brian : Thanks for the explanation. Fred : Have you tried 'emerge --distclean' at any stage? Something like (change as appropriate) emerge -DuavN world # ensure everything is up to date wrt USE flags revdep-rebuild emerge --distclean --pretend # get a list of packages that could be removed. and then, if appropriate emerge --distclean or emerge -C whichever packages as appropriate Then upgrade portage to latest and see if the problem is still present. Even if this doesn't solve the problem, you'll end up with a slightly more consistent system :) (In reply to comment #24) > Brian : Thanks for the explanation. > > Fred : Have you tried 'emerge --distclean' at any stage? > > Something like (change as appropriate) > emerge -DuavN world # ensure everything is up to date wrt USE flags > revdep-rebuild > emerge --distclean --pretend # get a list of packages that could be removed. > > and then, if appropriate > emerge --distclean > or > emerge -C whichever packages as appropriate > > Then upgrade portage to latest and see if the problem is still present. Even > if this doesn't solve the problem, you'll end up with a slightly more > consistent system :) > Thanks for the suggestion. With the substitution of --depclean for --distlean above, I followed your suggestions. Lots of things got removed. After this I ran revdep-rebuild and it wanted to emerge 17 things. At least two of them wanted files in /usr/lib64 that had been deleted. After copying one over from backups emerging, then seeing another that was needed, etc., etc., the process finally converged. I have now emerged the latest portage, and run emerge -Dau world and it found no updated packages. The process was a bit painful, but I'm glad to have this straightened out, at least on my system. I'm not convinced that there was not some kind of defect introduced in the recent portages, but evidently my system was not in an ideal state. My apologies to any who felt their time was wasted on this. Thanks again! Glad that it has been resolved! (feel free to close the bug) If you 'emerge --depclean' before 'emerge -N' and revdep-rebuild (which is what you appear to have done), it is more likely to be a problematic process - you remove packages that may still be needed by others. Fortunately, you had backups :) (In reply to comment #26) > Glad that it has been resolved! > (feel free to close the bug) > > If you 'emerge --depclean' before 'emerge -N' and revdep-rebuild (which is what > you appear to have done), it is more likely to be a problematic process - you > remove packages that may still be needed by others. Fortunately, you had > backups :) > O.K. I'll close the bug. And note that I followed exactly what you had suggested, except for running revdep after running emerge --depclean. My very limited experience with emerge --depclean is that it is somewhat hazardous. But the emerge -N was run before emerge --depclean, it however had nothing to do. Many thanks! |
