General Discussion  - 
 
What's the proposed upgrade path if you did not update #portage  in a #hardened  profile a long time? There is no way of reverting back because the profiles are not versioned in hardened...

# emerge -1a portage
!!! Unable to parse profile: '/etc/make.profile'
!!! ParseError: Profile contains unsupported EAPI '5': '/usr/portage/profiles/eapi-5-files/eapi'
!!! Your current profile is invalid. If you have just changed your profile
!!! configuration, you should revert back to the previous configuration.
!!! Allowed actions are limited to --help, --info, --search, --sync, and
!!! --version.
1
Tomáš Chvátal's profile photoMatthew Summers's profile photoKai Krakow's profile photoSven Vermeulen's profile photo
39 comments
 
Use 'eselect profile' to fix your make.profile symlink
 
Tried that, did not work... The profile link is not broken. It's pointing to "hardened/linux/amd64/no-multilib" as it always did - and that is the problem. While other profiles have a version inside (previously 10.1 vs. currently 13.0 in desktop profiles), the hardened profile is missing such a component.
 
Looks like your portage is too old to handle EAPI=5. I guess you could get  machine with the same architecture, build the portage and all dependencies with buildpkg, copy the binary packages over back to this machine and upgrade from the binary packages and see what happens next.
 
Yes, I know it is too old... That was the initial question - about the proposed upgrade path... Another idea: What about switching temporarily to a non-hardened profile? Or better not? I'd like to do as few changes to the system as possible. Running buildpkg with all deps on another machine would introduce way too many upgrades into the system. I just want to install security updates only (glsa-check) and switch a few useflags. This is not the only system that will be affected by this problem - so I need some general, minimal-invasive solution.
 
You could download the latest hardened portage snapshot and unpack it in /usr. 
 
Won't help as it will not solve the EAPI incompatibility between emerge (part of the portage package) as portage (as the snapshot/tree)... We are talking about portage as the package, not the snapshot. BTW: "emerge --sync" still works without problems so I have an up-to-date snapshot.
 
The snapshot includes the portage package.
 
I don't think the protage package in in the portage tree.
The package code lives in /usr/lib/portage
 
+Kai Krakow In that case i think you are screwed. Gentoo doesn't work this way. You either keep rolling forward or you get left behind.
 
OK, I was wrong about the portage package being in the snapshots.

Alternative tack. What arch are you on, +Kai Krakow? I have a hardened amd64 box here on 'stable' branch, I could binpkg a portage for you and you could unpack it onto your filesystem.
 
Thanks, +Will Keaney but I have a lot Gentoo systems active on stable hardened 64-bit, too... I could do it myself with binpkg. But, as +Jan Matějka pointed out, I suppose I am really screwed if I unpack a portage package from a much more current system to this old system (e.g. different python version) - then there'd be no way to move forward or backward from there on... Argh, the only real problem with this system is its old PHP 5.2 which we cannot (and may not) upgrade to 5.3, and 5.2 has been kicked from portage. Not a very nice move for long running server systems (last time I had it checked it had an uptime of 900+ days).
 
You could in theory set the profile to 10.0 and go with
emerge --nodeps -1 portage
set profile back
pretend it never happened
 
Another idea would be to dig out an old portage snapshot (the last for EAPI 4), upgrade portage, then sync back to the current one. Is that documented somewhere? (EAPI changes in portage tree)
 
But this still does not fix the bug.
We really should provide portage tarball that can be deployed on any system and fix this issue for everyone (at some point the 10.0 will disappear from profiles and this is really easy to fix by just adding new portage).
 
Sounds like an excellent candidate for bugs.gentoo.org ;-)
I've hit a lot of .. complicated update paths in my years with Gentoo, but I think this is the first time I've seen an EAPI conflict in the profiles.
 
So if you consider that a bug, +Tomáš Chvátal I'd like to post a bug report... Which info should go into it?
 
Well it is not bug in a profile but rather migration-path enhancement.
As I said in many of my presentations the migration period is pretty short sometimes so I would recommend having cron sync the portage tree and you have also automatic update for the portage itself or @system set if one can't afford @!world updates that often.

For the report I would go with enhancement request for infrastructure team to provide tinderbox binaries from current stable system. -> Afterall downloading small tarball and unpacking it to / is pretty easy.
 
Well, portage is already synced by cron (porticron to be exact) but I'd rather not like run "emerge -ua portage" from cron because it may pull all sorts of incompatible dependencies into the process... So maybe I should really quickpkg a portage from another system already on EAPI 5 and try that? After all it should not be so much different from a tarball from tinderbox? +Tomáš Chvátal 
 
I don't really know a clean upgrade path for hardened. What you could try is 1) manually set your profile symlink to a non-hardened 10.0 profile, 2) emerge -a portage, 3) afterwards immediately set your profile back to hardened. Whether that works depends on how many dependencies of portage need to be updated (ideally none).
 
So back to my first idea, got 2 points now... ;-)
 
Meanwhile, I discovered that almost all my machines are affected by this. I'm not very impressed by the idea to tinker around with production machines by unpacking tarballs or other fixing experiments and crossing fingers... I'm using Gentoo since 5+ years for production servers due to the high stability, individual feature configurability, and rolling upgrade pathes. But currently I am thinking of moving away from Gentoo: First PHP 5.2 was dropped (including dropping the supporting eclasses so I even could not keep those versions in an overlay), now this... :-(

Don't get me wrong: Dropping support for PHP 5.2 wasn't the problem. But completely removing the ebuilds (instead of hard-masking) made it impossible to rebuild PHP in case of broken library deps. And the upgrade path from PHP 5.2 to PHP 5.3 is a complete mess (well, dear PHP creators: you don't earn a prize for that, although 5.3 does many things better that 5.2 did wrong).
 
I assume you need this dead eclass: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/php5_2-sapi.eclass?hideattic=0&revision=1.34&view=markup&pathrev=MAIN

Of course, there are older versions in there, so maybe that helps. Similarly, you can view the dead php ebuilds and stick them in an overlay.

Here is a major issue. At a very basic level you must update portage as time progresses or you will end up with huge issues. There are no immunizations against updating with any distro. Nicely, its fairly easy to automate upgrades of key packages so this doesn't happen again.

I have some sympathy for you, but this is a hole you dug yourself, sorry to say. 

A solid path forward would be to write some scripts to fix the situation on a test machine, then roll that out to the rest of your prod line. A little proactivity will go a long way to insuring this doesn't bite you again.

Good luck!
 
Oh, one last thing, you can place eclasses in an overlay. It seemed like reading your post you thought that was not possible. Just create a directory called eclass in your overlay.
 
Thanks, +Matthew Summers but the actual problem is with EAPI 5 in Hardened... PHP 5.2 times are already gone, we took the hard path of migrating to 5.3. That was just an example for inconvenient upgrade pathes during the younger history of Gentoo... It caused a lot of headache and trouble. We never had such problems the years before.
 
So, talking with a fellow dev, he suggested an interesting potential solution:

manually symlink against a non-hardened 10.x profile
emerge -va1 portage
eselect profile your hardened profile

I think this is the simplest means and it was tested by a dev recently, more of less. :)
 
+Matthew Summers thats what've been stated on the thread already :-)

But still we should make all the profiles versioned so this does not happen.
 
Thanks, this is what I am doing and has already been proposed here. It still feels like tinkering... ;-)
 
Just to satisfy everyone's curiosity: Manually symlinking a 10.0 no-multilib profile, "emerge -1a portage", then going back to hardened: worked. I've got to rebuild bash and portage now back in the hardened profile (bash was pulled in as dependency). Seems to work without immediate side-effects.
 
It's been mentioned above, but i'd like to add my vote on it: pull in an older portage (tree) snapshot, upgrade there and go forward. I've been able to upgrade a 2009 deployment somewhere in december 2012 by using portage tree snapshots with about 3 to 4 months in between. The change you hit was introduced not that long ago; I think a snapshot from a month ago will suffice.
Add a comment...