Le lundi 21 janvier 2013 à 00:01 +0100, Thomas Sachau a écrit :
> Michał Górny schrieb:
> > Hello,
> > 
> > There is a fair interest in multilib and while still early, it would be
> > a good moment to decide on how USE flags to use for it.
> > 
> > The current attempts are mostly using USE=multilib which is not really
> > expressive and poor. What I would go for is a clear variable specifying
> > which targets package is built for.
> > 
> > 
> > This raises the following questions:
> > 
> > 1) do we want the default ABI to be switchable?
> > 
> > 2) do we want irrelevant ABIs to be visible to emerge users?
> > 
> > By 2) I mean: do we want the users to see stuff like:
> > 
> >   MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1)
> >     (-ppc64_abi2) (-ppc64_abi3) ..."
> > 
> > or just the relevant part.
> > 
> > To be honest, I don't know if there's other way to hide USE flags than
> > using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split
> > the flags per-arch, i.e. have:
> > 
> >   MULTILIB_AMD64="abi1 abi2 abi3"
> >   MULTILIB_PPC64="abi1 abi2 abi3"
> > 
> > with appropriate USE_EXPAND_HIDDEN set by profiles.
> > 
> > 
> > What are your thoughts? Which arches would like to use multilib? What
> > names for ABIs do you suggest?
> > 
> 
> So you want to re-implement multilib-portage in an eclass without the
> additional benefits a package-manager level implementation has?

Well that's the point of the eclass that was proposed a few days ago
allow building multiple ABIs. Having clear USE-dep like python-r1.eclass
is imho the way to go.

As said in another reply of this thread, USE=multilib really is a
solution that has its problems (no fine PM control for ABIs, slow
updates of emul-pkgs) to the current problem and portage-multilib, well
it's a subject that pops up from time to time I have no idea how and
will it will come nor do I have time to help on that front.

However this eclass would enable quick and easy per-ebuild support for
multiple ABIs just like python-r1 and friends, and this is a good thing
for every maintainer that wants to provide this kind of support. I know
I would, at least to get rid of the always lagging emul packages.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo