Concerning the events of a fresh install, beginning from stage2 on 12/10/2003: ------------------------------------------------------------------------------ Installation is smooth untill `emerge -u system`. Process initially fails at openssl-0.9.7c-r1, erroring out that it requires Perl 5. `emerge -up system` shows Perl is to be built, but later in the chain after openssl. `emerge -u perl` fails as openssl again attempts to build before Perl. `emerge perl` (no -u) successfuly builds Perl and allows me to continue. Later a similar situation happens. python-2.3.2-r2 fails as it claims to require portage-2.0.49-r16. Current portage version installed is portage-2.0.49-r4 from stage2-pentium4-20030910.tar.bz2. portage-2.0.49-r18 is slated to be installed, but requires python. I have not gotten around this issue yet. Various stages of success come with combinations of `emerge <package>` and `emerge -u <package>`, coaxing the system to get certain packages installed in the correct order. This most likely would be an issue with a stage1 install as well, but I'm assuming not with a stage3 or GRP install. -- Platform for this bug has been set to x86 since that is the hardware I'm working with at the moment, though I can see how this would affect other platforms as well. Severity set to critical since a solution to this problem may not be obvious or even hopeful to an new/average user. Component set to 'Core system' since this does not directly apply to any other option.
Appologies, as I forgot to mention I'm using ACCEPT_KEYWORDS="~x86", as you may have figured out by now, though I'm not using it outside the scope of the installation docs. The install docs only mention not to set ACCEPT_KEYWORDS="~arch" untill after stage1 in complete. Since this is a stage2 install I felt it was "safe". Had I remembered this prior to the initial bug submission I wouldn't had set severity to a lower level. Current status: --------------------------- ## ## BEGIN SCREEN OUTPUT ## >>> emerge (7 of 57) dev-lang/python-2.3.2-r2 to / >>> md5 src_uri ;-) Python-2.3.2.tgz * Dependency Failed! Requires >=sys-apps/portage-2.0.49-r16 !!! ERROR: dev-lang/python-2.3.2-r2 failed. !!! Function pkg_setup, Line 47, Exitcode 0 !!! Requires >=sys-apps/portage-2.0.49-r16 cdimage root # emerge python -p These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] dev-lang/python-2.3.2-r2 cdimage root # emerge portage -p These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] dev-lang/python-2.3.2-r2 [ebuild U ] sys-apps/portage-2.0.49-r18 [2.0.49-r4] cdimage root # ## ## EOF ## I cannot force an install of portage-2.0.49-r16 because the only versions contained in the current tree are -r15 and -r18. Also note that `emerge python -p` from above does not list any deps, even though it fails because of missing deps. Viewing python-2.3.2-r2.ebuild I can't find any mention of a direct, specific portage version dependancy. By hand I can emerge python-2.2.3-r5 just fine, chosen because it's the highest, non-2.3.x version, and I can then emerge portage-2.0.49-r18 since it's dep is set to >=python-2.2.1. After emerging the latest portage I can now update to the latest python. Now, after running python-update as mentioned in the output of python-2.3.2-r2, all required packages are rebuilt against it, I unmerge 2.2.3 and rebuild portage just to be sure. Everything looks good. In summary, this is most easily described as a portage/python dependancy problem when installing with ACCEPT_KEYWORD="~x86" on a pre-stage3 setup.
do we support people bootstrapping and stage building with ~x86? ~x86 is for testing, and it seems hard to support people stage building at that level. for the python problems, you need to "emerge portage" and get the latest portage installed. otherwise you'll experience serious problems. until we have stages with python 2.3.2 as default, i don't think it'll be possible to avoid this.
Agreed. If I had remembered I stuck ACCEPT_KEYWORDS="~x86" in that early I probably wouldn't have submitted this report. Having said that, and for the record, after chasing my tail for a bit and eventually getting everything installed there don't seem to be any problems. Also, while I'm not argueing your point or stance on the subject, the install doc itself makes mention of using ~x86 at that stage. In a warning block in section 10 (http://www.gentoo.org/doc/en/gentoo-x86-install.xml#doc_chap10): "Warning: Advanced users: If you are planning on installing an ACCEPT_KEYWORDS="~x86" Gentoo system, do not set ACCEPT_KEYWORDS until the bootstrap phase (stage1) is done." I could argue that there is enough language there to suggest the feasability of setting ~x86 that early in the process. And as that is the official installation document a user could infer an implied level of support. The easiest fix would be to amend the above statement, describing immediate post-stage1 ~x86 installs may be unpredictable. Sorry, part of my job is QA. Close this if you like. Cheers.
matt, i hope i didn't come across as dismissing your problem. in fact, i too want to find a solution to it. currently it isn't a very elegant and things "should" work well, even in ~arch. however, i haven't yet come up with a clean solution for this problem. maybe if someone could suggest a solution to this, i'll be very happy to implement it. one thing i've thought about is to remove portage's python dep and make python depend on portage. i'm not sure if it'll work and would probably cause other problems for stage building.
We really should not have to support ~arch in installation stage.
Seemant, but is this a solution? ~ARCH today is ARCH tomorrow. You loose the chance to spot upcoming errors in an early stage. I think everybody is aware of possible negative outcome if they get warned. I did the stage1 installation today and switched to ~ARCH after bootstaping. I had no problems with perl and openssl. The python-portage issue could be solved by emerging an 'old' python version, emerge portage, emerge 'new' python version, python-updater. Or injecting dev-lang/python-2.3.2-r2, then emerge portage, and emerge python, than python-updater seems to work too (, but this leaves ophaned files from bootstraping in /usr/lib/python-2.2/ which get removed if you emerge python-2.2 and clean it later again, or am i wrong?.)
Hello, I had the same problem as you a few days ago, and I found out that changing ">=sys-apps/portage-2.0.49-r16" to ">=sys-apps/portage-2.0.49-r15" in the python ebuild. This is reported in bug35592, where another solution was given, that, I believe, is much more trustworthy and elegant: emerge without update option. The question I'm now asking myself (and here at the same time) is: Why this dependency on a non-existent portage revision ? Is it an error, or was written in the purpose of forcing portage2.0.49-r18 update before python-2.3.2-r2 ? In other words, how can I trust the turnaround I found ?
Oops ! I did not finish one sentence. Sorry for my poor english... "I found out that changing [...] allowed the build of python, and portage afterwards."
I can remove ~arch information from the installation guide (or explicitly mention that they should not use ~arch at all if they don't know what they are up to).
No worries Alastair, I'm not really taking one side of the issue or the other myself, just looking for exploration. A few times I've run into package problems that only show up during an install. I'm not directly in favor of you supporting ~arch installs, but you may not get to know the depth of things like the portage/python problem without that experience. And while the portage/python problem itself may seem trivial at the moment, the question of supporting ~arch during install is pretty large. I still think the best fix is to change the language in the install docs. Maybe mention it may not be a good idea to set ~arch untill after `emerge system`? I'll keep interjecting here as long as this is open, so closing it is the easiest way to shut me up, which I won't object to.
The matching portage version was pulled due to a bug... This is presently taken care of. The reason we shouldn't be overly concerned with ~arch is that we cannot guarentee that particular versions of a package is available in unstable. Depending on something that is in flux isn't healthy, and as shown by this case, we can't ensure that it always works. The maintainers of packageX might break packageY when they have to yank an ebuild.
Okay, I'll update the docs then...
Created attachment 22127 [details, diff] Patch to hb-install-stage.xml This patch removes all the blabla about ACCEPT_KEYWORDS for ~ARCH and hard-masked packages, and replaces it with: """ The other two trees (<e>~ARCH</e> and hard-masked ebuilds) are not meant to be used during the installation as they occasionally break the installation process. """ I believe this is the best approach here?
ACCEPT_KEYWORDS should never have anything except '~arch' in it. We shouldn't be opposed to it, just note that it isn't something that we aren't going to invest great amounts of time in figuring out.
Boy I hope you mean 'arch' and not '~arch'
Okay, I've applied the patch to the installation instructions. Shall I mark this one as fixed, or does something else need to happen?
Okay, marking this as FIXED.
