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