1 |
On Mon, 21 Jan 2013 01:05:56 +0300 |
2 |
Sergei Trofimovich <slyfox@g.o> wrote: |
3 |
|
4 |
> On Sun, 20 Jan 2013 20:11:31 +0100 |
5 |
> Michał Górny <mgorny@g.o> wrote: |
6 |
> |
7 |
> > There is a fair interest in multilib and while still early, it would be |
8 |
> > a good moment to decide on how USE flags to use for it. |
9 |
> > |
10 |
> > The current attempts are mostly using USE=multilib which is not really |
11 |
> > expressive and poor. What I would go for is a clear variable specifying |
12 |
> > which targets package is built for. |
13 |
> |
14 |
> You just need to add 'ABI' and 'MULTILIB_ABIS' to |
15 |
> "emerge --info ${pkg}" output. |
16 |
|
17 |
No, that's not the same. It's like python.eclass vs new Python |
18 |
eclasses. Cheap hidden logic vs explicit USE-dep logic. |
19 |
|
20 |
> Do you plan to keep precise depends for packages? |
21 |
> like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32. |
22 |
|
23 |
Yes. ${MULTILIB_USEDEP} is for that (it currently evaluates |
24 |
to 'multilib?'). |
25 |
|
26 |
> What to do if someone builds a package only with non-default ABI? |
27 |
> (it means installed package does not quite work for default ABI) |
28 |
|
29 |
Well, I was asking the same question. That was what my q1 was asking, |
30 |
I think you misunderstood it. |
31 |
|
32 |
> like on ABI=amd64 media-libs/glu[ABI=x32] could not be used by |
33 |
> any of ABI=amd64 users. |
34 |
> |
35 |
> In order to track such depends precisely you would need to add |
36 |
> ABI flags to each revdep recursively. It's quite invasive. Is it worth |
37 |
> the effort? |
38 |
|
39 |
A good point. I'd say that the default impl should be built then. |
40 |
But... how about making it a USE flag with use.force logic? That way, |
41 |
it would be explicitly visible, and if someone really wanted to disable |
42 |
it, he would be able to do it on his own responsibility. |
43 |
|
44 |
> Currently USE=multilib means 'build for all toolchain-supported' ABIs. |
45 |
> It looks clean and short. |
46 |
|
47 |
But if we wanted to introduce x32, it would become no longer clean. I |
48 |
believe many of our users want/need multilib only for running 32-bit |
49 |
apps on amd64 (like wine). Why would they need x32 libraries? |
50 |
|
51 |
But on the other hand, if we follow that logic we will probably have |
52 |
no reason to enable x32 on amd64 for a long time. Maybe mips ABIs will |
53 |
be a better example? |
54 |
|
55 |
> > 2) do we want irrelevant ABIs to be visible to emerge users? |
56 |
> > |
57 |
> > By 2) I mean: do we want the users to see stuff like: |
58 |
> > |
59 |
> > MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) |
60 |
> > (-ppc64_abi2) (-ppc64_abi3) ..." |
61 |
> |
62 |
> Would adding irrelevant ABIs trigger rebuilds on world update? |
63 |
|
64 |
That's a good question, especially wrt USE_EXPAND_HIDDEN. |
65 |
|
66 |
> Do you intermingle gentoo's $ARCH and ABI? |
67 |
|
68 |
I think not. I believe that ABIs shall be defined by profiles. |
69 |
If someone tries to set ARCH for something incorrect for the profile, |
70 |
that's not something we shall support, I believe. |
71 |
|
72 |
> How many ABI vars do you expect to see for simple "common" cases? |
73 |
> |
74 |
> x86_64-pc-linux-gnu-gcc -m32 (host ARCH=amd64) |
75 |
> x86_64-pc-linux-gnu-gcc -m64 (host ARCH=amd64) |
76 |
> x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=amd64) |
77 |
> i686-pc-linux-gnu-gcc -m32 (host ARCH=x86) |
78 |
> i686-pc-linux-gnu-gcc -m64 (host ARCH=x86) |
79 |
> i686-pc-linux-gnu-gcc -mx32 (host ARCH=x86) |
80 |
> |
81 |
> 3 or 6? |
82 |
|
83 |
I think 3 will be enough. |
84 |
|
85 |
> Looks like insane amount of metadata growth for each |
86 |
> plagued package. |
87 |
|
88 |
I don't think metadata is really important here. I believe that |
89 |
the amount of additional metadata introduced by the packages affected |
90 |
by multilib is not really one worth worrying. |
91 |
|
92 |
-- |
93 |
Best regards, |
94 |
Michał Górny |