As of this writing only the 3.1.2 ebuild exists for app-emulation/xen and app-emulation/xen-tools. Now if the upgrade process to this new version was without issues and if this components was not one of the central parts of a system, then it may have been ok to remove all of the former versions from portage, but it is not. In the process of upgrading to the new 3.1.2 version the old version (in my case 3.0.2) the new version overwrites the formers files, which then means that you can't boot the system with the former xen kernel (ex. /boot/xen.gz), as it is not there. And if you manually made a backup of xen.gz and adjusted the boot configuration, you would only be able to boot dom0 and not any domU's as the xen-tools also had been replaced with the new and incompatible version. Now my upgrade to this new version did not go smooth at all, and without any of the former ebuilds available my options was limited to 1. figure out what was wrong and get it to work, 2. restore my system from a backup had the former ebuilds been available I would have been able to downgrade to the former version (quicker that a restore), get my system up and running, and take a break during the failed upgrade. I would therefore like to request that ebuilds for xen, xen-tools, xen-sources... not to be removed in the future. Or alternatively that multiple versions of xen can be installed and cooperate on the same dom0 system. Reproducible: Always
You can get any old ebuild from http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-emulation/xen/?hideattic=0 Keeping unsupported vulnerable stuff in the tree indefinitely is not an option, sorry.
