I'm not sure if this collides with some policy on dep handling, but it would be really nice if binpkgs would automatically RDEPEND on the python version they were built with.
Because right now, if a binpkg was built with an updated python but the ebuild didn't explicitly RDEPEND on that version/slot, the binpkg merge will fail if the updated python isn't already installed for some other reason.
Now I'm not sure if this breaks ebuild/tbz2 dependency semantics, but it would be really nice if the used python version was automatically added to RDEPEND in the Packages index file. That is, if we can afford to deviate from what the ebuild says.
I'm not on the dev-portage team, but I consider it proper binhost maintenance to run the tools to rebuilds packages after major upgrades (eg. python-updater). I'll add myself to CC to listen.
(In reply to comment #1)
> I'm not on the dev-portage team, but I consider it proper binhost maintenance
> to run the tools to rebuilds packages after major upgrades (eg.
> python-updater). I'll add myself to CC to listen.
The problem is not on the binhost. The use case I'm talking about is this:
binhost updates python to 2.7, then builds pkg-xy with python:2.7
client has not yet upgraded to python:2.7 (only 2.6 available) and tries to emerge pkg-xy as binpkg. This fails because pkg-xy was built with python:2.7 which is not available.
This requires some form of ABI dependency metadata, related to bug 192319.
Note that this would Just Work(tm) if USE_PYTHON was done as a USE_EXPAND with appropriate conditional deps, similar to RUBY_TARGETS.