1 |
Gilles Dartiguelongue schrieb: |
2 |
> Le lundi 21 janvier 2013 à 00:01 +0100, Thomas Sachau a écrit : |
3 |
>> Michał Górny schrieb: |
4 |
>>> Hello, |
5 |
>>> |
6 |
>>> There is a fair interest in multilib and while still early, it would be |
7 |
>>> a good moment to decide on how USE flags to use for it. |
8 |
>>> |
9 |
>>> The current attempts are mostly using USE=multilib which is not really |
10 |
>>> expressive and poor. What I would go for is a clear variable specifying |
11 |
>>> which targets package is built for. |
12 |
>>> |
13 |
>>> |
14 |
>>> This raises the following questions: |
15 |
>>> |
16 |
>>> 1) do we want the default ABI to be switchable? |
17 |
>>> |
18 |
>>> 2) do we want irrelevant ABIs to be visible to emerge users? |
19 |
>>> |
20 |
>>> By 2) I mean: do we want the users to see stuff like: |
21 |
>>> |
22 |
>>> MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) |
23 |
>>> (-ppc64_abi2) (-ppc64_abi3) ..." |
24 |
>>> |
25 |
>>> or just the relevant part. |
26 |
>>> |
27 |
>>> To be honest, I don't know if there's other way to hide USE flags than |
28 |
>>> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split |
29 |
>>> the flags per-arch, i.e. have: |
30 |
>>> |
31 |
>>> MULTILIB_AMD64="abi1 abi2 abi3" |
32 |
>>> MULTILIB_PPC64="abi1 abi2 abi3" |
33 |
>>> |
34 |
>>> with appropriate USE_EXPAND_HIDDEN set by profiles. |
35 |
>>> |
36 |
>>> |
37 |
>>> What are your thoughts? Which arches would like to use multilib? What |
38 |
>>> names for ABIs do you suggest? |
39 |
>>> |
40 |
>> |
41 |
>> So you want to re-implement multilib-portage in an eclass without the |
42 |
>> additional benefits a package-manager level implementation has? |
43 |
> |
44 |
> Well that's the point of the eclass that was proposed a few days ago |
45 |
> allow building multiple ABIs. Having clear USE-dep like python-r1.eclass |
46 |
> is imho the way to go. |
47 |
> |
48 |
> As said in another reply of this thread, USE=multilib really is a |
49 |
> solution that has its problems (no fine PM control for ABIs, slow |
50 |
> updates of emul-pkgs) to the current problem and portage-multilib, well |
51 |
> it's a subject that pops up from time to time I have no idea how and |
52 |
> will it will come nor do I have time to help on that front. |
53 |
|
54 |
multilib-portage exists and works for years, the problem usually is, |
55 |
that posts about it are ignored until i write something about "planned |
56 |
to ask council", which results in new requests to be fulfilled (for the |
57 |
inclusion of this feature in the next EAPI). This could also get us rid |
58 |
of USE=multilib and the emul packages. ;-) |
59 |
|
60 |
> However this eclass would enable quick and easy per-ebuild support for |
61 |
> multiple ABIs just like python-r1 and friends, and this is a good thing |
62 |
> for every maintainer that wants to provide this kind of support. I know |
63 |
> I would, at least to get rid of the always lagging emul packages. |
64 |
|
65 |
As already written in another thread not long ago, the USE flag part |
66 |
(shown USE flags per arch and USE flag dependencies) will be pretty hard |
67 |
to implement at eclass level. So i will wait and see, if someone can |
68 |
surprise me with a solution, that works as good as multilib-portage |
69 |
without bad side effects or additional work for all sides. |
70 |
|
71 |
|
72 |
-- |
73 |
|
74 |
Thomas Sachau |
75 |
Gentoo Linux Developer |