|Summary:||emerge could allow upgrading blockers first when only RDEPEND-ed|
|Product:||Portage Development||Reporter:||Joe Wells <sllewbj>|
|Component:||Core - Dependencies||Assignee:||Portage team <dev-portage>|
|Package list:||Runtime testing required:||---|
Description Joe Wells 2006-07-01 06:04:49 UTC
Consider these three new ebuilds: dev-java/java-config-wrapper-0.9-r5 dev-java/java-config-2.0.26 dev-java/java-config-1.3.0-r2 These are replacing this single old ebuild: dev-java/java-config-1.2.11-r1 Because both of the new java-config ebuilds RDEPEND on java-config-wrapper, emerge decides to install them after the new java-config-wrapper ebuild. However, the java-config-wrapper ebuild lists the older java-config ebuild as a blocker. So emerge is stuck as a result. Because the dependencies are only RDEPEND's, it is actually okay to install the newer java-config-1.3.0-r2 ebuild before installing the java-config-wrapper ebuild, provided both are installed in the same run. This would allow things to proceed automatically. Is it possible that this could be done? I'm guessing this might need to be a longer-term portage goal rather than something that could be done quickly. Obviously, there is a risk if installing the new java-config-1.3.0-r2 ebuild succeeds and installing the new java-config-wrapper fails. If this happens, the user would need to be warned that an RDEPEND of java-config-1.3.0-r2 was not successfully installed and that they should consider reverting. Yes, I know that there are instructions at http://www.gentoo.org/proj/en/java/java-upgrade.xml to remove the old java-config first. I still think it is a bug because it would be much better if ordinary users didn't have to read every upgrade guide. Things should just work. You might choose to consider this an enhancement request rather than a bug.