On 06/26/11 21:48, Thomas Sachau wrote:
> I am thinking about a solution for those similar to current ruby idea and already implemented for
> cross-compilation in my multilib-portage branch of portage. The very short version:
> Set the needed details in the ebuilds, where needed, in case of revdep-rebuild, either adjust the
> SLOT var for each change requiring a rebuild of depending packages or using some new var, e.g.
> API_SLOT for this. Ebuilds depending on packages like python or perl should define the range of
> versions they support.
> Now portage generates a (use_expanded) list of USE flags for depending packages, e.g. for a package
> depending on python-2.6 and 2.7 it adds something like PYTHON_DEPEND="pyhon26 python27" to the list
> of USE flags. If there is only one dependency installed (like perl or changing libs), this could be
> a hidden USE flag.
> When the dependency is now updated, the USE flags will change, so in case of portage, a --newuse
> will catch those changes and shows those packages in the list of packages, that need to be emerged
> In case of slotted dependencies (like python, ruby or php), this would also allow the user to define
> per package, if he wants support for one or more slots of e.g. python.
This sounds pretty good on the surface... the devil as always is in the
details, and I'll have to have a look. I take it though, this would be
exclusively tackling the domains of Python and Perl modules? Or does it
also tackle ABI breakage of other packages?
Sounds like the SLOT variable could get quite unwieldy where several
SLOT-ed packages contribute to a package.
Stuart Longland (aka Redhatter, VK4MSL) .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer '.'` :
. . . . . . . . . . . . . . . . . . . . . . .'.'
I haven't lost my mind...
...it's backed up on a tape somewhere.