Was doing a fresh install of gentoo with liveCD for x86 athlon XP. When it comes to building the system with "emerge system" everything goes nice until it
Was doing a fresh install of gentoo with liveCD for x86 athlon XP. When it comes to building the system with "emerge system" everything goes nice until it´s´time to upgrade ports that want a newer version of python and python wants a newer version of portage. More poeple who has encountered probably the same problem and discussion in gentoo.org forum (URL above). All who got the problem were doing stage 2 install for athlon XP. Reproducible: Always Steps to Reproduce: 1.install 2.update system "emerge system" 3. Actual Results: cant get a newer version of portage that is needed for further update Expected Results: Continued updating athlon XP 2500+ barton
Fixed in CVS. The check was put back in place to prevent people from updating python without upgrading portage. Until we can have the check and a smooth installation, users doing the right thing will take precedence.
*** Bug 43069 has been marked as a duplicate of this bug. ***
what is going on? why are people putting that check back in without checking with me? it should work fine with both (pentium4) 1.4 stages and the 2004.0 stages that i've tested. can anyone point to more evidence that it is not the case?
The problem of python being updated before portage comes when a user with an existing installation updates other software requiring python before updating portage itself. perhaps the best solution is to have emerge's warning to update portage straight away be more direct. Essentially the problem that was attempted to be fixed is caused by users doing something erroneous with out realizing their error.
if you are installing cleanly from the stages, portage works fine with python2.2 even when python2.3 is installed (they're slotted.) moreover, jason, you should not be touching ebuilds that belong to the python herd without consulting with me or the python team. it is just plain irresponsible, everything in that ebuild has been done with a reason.
yes, i am aware that they are slotted and that i should not modify the ebuilds without consultation of the python herd. i did not personally reinstate the check, i only removed it again as i was aware that it was causing the problem outlined in this bug. furthermore, the change that i did do was done after some small discussion on #gentoo-dev. normally i would leave the change to be done by the team responsible, but in this case i felt that it was necessary to be done as soon as possible.
jason, sorry, after reading thru the changelog, i realised that you did the right thing. but in the future, please email the herds involved if you are going to touch ebuilds that you are not maintaining.
