From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: slyfox@gentoo.org
Subject: Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
Date: Sun, 20 Jan 2013 23:33:39 +0100 [thread overview]
Message-ID: <20130120233339.15b57eab@pomiocik.lan> (raw)
In-Reply-To: <20130121010556.27f8fac6@sf>
[-- Attachment #1: Type: text/plain, Size: 3515 bytes --]
On Mon, 21 Jan 2013 01:05:56 +0300
Sergei Trofimovich <slyfox@gentoo.org> wrote:
> On Sun, 20 Jan 2013 20:11:31 +0100
> Michał Górny <mgorny@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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
next prev parent reply other threads:[~2013-01-20 22:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-20 19:11 [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib Michał Górny
2013-01-20 22:05 ` Sergei Trofimovich
2013-01-20 22:33 ` Michał Górny [this message]
2013-01-21 13:34 ` Alexis Ballier
2013-01-20 23:05 ` Thomas Sachau
2013-01-20 23:01 ` Thomas Sachau
2013-01-20 23:08 ` Michał Górny
2013-01-20 23:10 ` Gilles Dartiguelongue
2013-01-20 23:52 ` Thomas Sachau
2013-01-20 23:59 ` Chí-Thanh Christopher Nguyễn
2013-01-21 1:31 ` Matt Turner
2013-01-21 13:27 ` Alexis Ballier
2013-01-21 16:55 ` Michał Górny
2013-01-23 8:24 ` Michał Górny
2013-01-23 11:03 ` Alexis Ballier
2013-01-23 15:27 ` Michał Górny
2013-01-23 15:44 ` Michał Górny
2013-01-23 17:36 ` Alexey Shvetsov
2013-01-23 18:48 ` Alexis Ballier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130120233339.15b57eab@pomiocik.lan \
--to=mgorny@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=slyfox@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox