| Summary: | media-libs/mesa-7.10: fails to build during a fresh install from minimal livecd because dev-libs/libxml2-2.7.7 isn't pulled in | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | James Dominy <jgdominy> |
| Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | jgdominy |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Build log | ||
|
Description
James Dominy
2011-02-06 11:30:28 UTC
Attach full build log. Created attachment 261789 [details]
Build log
Sorry about that, I've attached it now
It seems it's a matter of order: mesa does depend on libxml2[python], but you've got both python 2.6 and 2.7, so it's likely things will get working again after python-updater and 'eselect python'. On unrelated note: 'ACCEPT_KEYWORDS="x86 ~amd64"' is just asking for trouble, keep it in one arch. (In reply to comment #3) > It seems it's a matter of order: mesa does depend on libxml2[python], > but you've got both python 2.6 and 2.7, so it's likely things will get working > again after python-updater and 'eselect python'. > > On unrelated note: 'ACCEPT_KEYWORDS="x86 ~amd64"' is just asking for trouble, > keep it in one arch. > This is a fresh install, any reason I would be getting two versions of python? re ACCEPT_KEYWORDS: Thanks for spotting that, copied my make.conf over from an amd64 machine and edited. Fixed now. Surely I shouldn't have to run python-updater during a system install, especially if it's needed mid 'emerge system'. Mind you I think I've figured this out. The stage3 contains python-2.6. When I edited make.conf with ACCEPT_KEYWORDS="~x86" (ignoring the ~amd64 screw up) python-2.7 was installed. But none of the python modules were updated (hence as you say a need for python-updater), although given my USE flags there was a bunch of extra stuff pulled into system, including mesa. Is there a way to make this sort of ting not require manual intervention. It occurs to me that having portage check python dependencies specially might do the trick, e.g. check not only that they've been emerged, but also that they were emerged into the current version of python. I don't know how hard this would be to implement. It is possible that your amd64 make.conf also set CHOST in a way that would break things. The stage3 that you used for installation is stable. If you upgrade to unstable python, then running python-updater is needed. re copying the amd64 make.conf, I took the stage 3 make.conf's values and replaced the amd64 make.conf values with them. As you can see in my emerge info, the CHOST value is the standard. re python updater and upgrading to arch, thanks for the explanation. It makes sense now why it's necessary. I only wonder now if it can't be automatic? Would it be unreasonably difficult to treat certain packages like portage, such the when they are upgraded, the current emerge pause, reloads with new version of portage, and continues. Except instead of reloading portage, python-updater or perl-cleaner could be run, and maybe force an eselect on the user (although this makes the process interactive which may not be desirable) |
