On Mon, 21 Jan 2013 01:05:56 +0300 Sergei Trofimovich <sly...@gentoo.org> wrote:
> On Sun, 20 Jan 2013 20:11:31 +0100
> Michał Górny <mgo...@gentoo.org> wrote:
>
> > 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.
>
> You just need to add 'ABI' and 'MULTILIB_ABIS' to
> "emerge --info ${pkg}" output.
No, that's not the same. It's like python.eclass vs new Python
eclasses. Cheap hidden logic vs explicit USE-dep logic.
> Do you plan to keep precise depends for packages?
> like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32.
Yes. ${MULTILIB_USEDEP} is for that (it currently evaluates
to 'multilib?').
> What to do if someone builds a package only with non-default ABI?
> (it means installed package does not quite work for default ABI)
Well, I was asking the same question. That was what my q1 was asking,
I think you misunderstood it.
> like on ABI=amd64 media-libs/glu[ABI=x32] could not be used by
> any of ABI=amd64 users.
>
> In order to track such depends precisely you would need to add
> ABI flags to each revdep recursively. It's quite invasive. Is it worth
> the effort?
A good point. I'd say that the default impl should be built then.
But... how about making it a USE flag with use.force logic? That way,
it would be explicitly visible, and if someone really wanted to disable
it, he would be able to do it on his own responsibility.
> Currently USE=multilib means 'build for all toolchain-supported' ABIs.
> It looks clean and short.
But if we wanted to introduce x32, it would become no longer clean. I
believe many of our users want/need multilib only for running 32-bit
apps on amd64 (like wine). Why would they need x32 libraries?
But on the other hand, if we follow that logic we will probably have
no reason to enable x32 on amd64 for a long time. Maybe mips ABIs will
be a better example?
> > 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) ..."
>
> Would adding irrelevant ABIs trigger rebuilds on world update?
That's a good question, especially wrt USE_EXPAND_HIDDEN.
> Do you intermingle gentoo's $ARCH and ABI?
I think not. I believe that ABIs shall be defined by profiles.
If someone tries to set ARCH for something incorrect for the profile,
that's not something we shall support, I believe.
> How many ABI vars do you expect to see for simple "common" cases?
>
> x86_64-pc-linux-gnu-gcc -m32 (host ARCH=amd64)
> x86_64-pc-linux-gnu-gcc -m64 (host ARCH=amd64)
> x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=amd64)
> i686-pc-linux-gnu-gcc -m32 (host ARCH=x86)
> i686-pc-linux-gnu-gcc -m64 (host ARCH=x86)
> i686-pc-linux-gnu-gcc -mx32 (host ARCH=x86)
>
> 3 or 6?
I think 3 will be enough.
> Looks like insane amount of metadata growth for each
> plagued package.
I don't think metadata is really important here. I believe that
the amount of additional metadata introduced by the packages affected
by multilib is not really one worth worrying.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
