This bug is for feedback and bug reporting on EAPI=4-slot-abi testing , as provided by the portage tree fork found in my developer overlay: http://git.overlays.gentoo.org/gitweb/?p=dev/axs.git OVERLAY USAGE: 0 - check the website to make sure my overlay is not too out-of-date compared to your copy of the tree. I am trying to keep the overlay in sync within 24h of CVS HEAD, but it is difficult as only part of the upgrade can be automated. 1 - emerge =sys-apps/portage-9999 to obtain a copy of portage supporting EAPI=4-slot-abi 2 - obtain a copy of my overlay (layman -f ; layman -a axs) 3a - gradually upgrade your system, replacing packages from portage with the overlay's EAPI=4-slot-abi equivalent versions. Alternatively, emerge -e @world to replace 'em all. 3b - instead of re-emerging, use my portage-vdb hack to simulate the re-emerging of all installed EAPI=4 packages to their overlay equivalents. This is what I do, but be warned that this is not something to be taken lightly (unless you're on a disposable image like a chroot) and may cause severe breakage of portage. 3b.1 - unless you feel very lucky, make a backup of /var/db/pkg 3b.2 - run /var/lib/layman/axs/hack-4slotabi-into-portagedb.sh, watch for errors in the output or anything that seems particularly odd. 3b.3 - run emerge -uDp @world to check if it worked and all seems OK. 3b.4 - DO NOT emerge anything until you are sure that the vdb is OK. If in any doubt, restore the backup.
On 02/07/12 02:01 AM, Vaeth wrote: > For those who want to test EAPI=4-slot-abi, > I suggest to install >=eix-0.26.0 which can deal with subslots. >
EAPI5 has been enabled for in-tree ebuilds for a few months now, closing the bug. I've also not updated my overlay for a few months so I'm going to drop the ebuilds.
