1 |
(I'm resending this email as the original apparently did not make it |
2 |
to the list, although Thomas probably received it) |
3 |
|
4 |
Hi Thomas, |
5 |
|
6 |
I'm replying to the original thread below to allow those who have |
7 |
missed it to have the full context. |
8 |
|
9 |
On Sun, Aug 16, 2009 at 5:37 AM, Thomas Sachau <tommy@g.o> wrote: |
10 |
> Let me introduce a nice project, which was started by some users: |
11 |
> |
12 |
> Since the emul-linux-x86-* packages for 32bit libs for amd64 users are neither easy to maintain nor |
13 |
> up-to-date, some users started to implement an eclass, which allows to build requested libs with |
14 |
> additional 32bit support. Later i joined them and helped them improving it a bit, but it was and |
15 |
> still is mainly their project, they do the main work keeping this overlay up-to-date. |
16 |
> |
17 |
> Also this overlay is a nice idea to drop emul-linux-x86-* packages, it either requires continual |
18 |
> work or modification of many ebuilds in main tree to support this in long term. To avoid this, i |
19 |
> took the original multilib portage patch from kanaka, adjusted it to the current portage code and |
20 |
> added the ideas and code from the eclass version. The result is now a portage, which is able to |
21 |
> build any ebuild with additional 32bit lib support. |
22 |
> |
23 |
> The current main regression are ebuilds and eclasses, which do not support this (e.g. perl modules |
24 |
> and mysql). |
25 |
> |
26 |
> If anyone is interested: |
27 |
> |
28 |
> -for the eclass version, which is mainly maintained by users and is mainly intended to only replace |
29 |
> the emul-linux-x86-* package: just add it via "layman -a multilib" (it should be pretty stable and |
30 |
> mostly working). |
31 |
> |
32 |
> -for the portage version: It is also in the multilib overlay, but in a different branch called |
33 |
> portage-multilib. To use this, you should read the instructions at [1] |
34 |
> (doc/portage-multilib-instructions). This one should also mainly work, but there is probably a good |
35 |
> amount of packages in the main tree, which may refuse to work with it. |
36 |
> |
37 |
> Bugreports: preferred way is #gentoo-multilib-overlay at irc.freenode.org, but we also have an |
38 |
> alias, where you can contact us: multilib@g.o |
39 |
> |
40 |
> [1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib |
41 |
> -- |
42 |
> Thomas Sachau |
43 |
> |
44 |
> Gentoo Linux Developer |
45 |
|
46 |
I have already explained that I think it's a wonderful project and I |
47 |
definitely would like to see it in the tree sooner rather than later. |
48 |
There was a discussion on the council alias where everybody who |
49 |
participated seemed to like it too. |
50 |
|
51 |
However the consensus was that the project wasn't mature enough (I |
52 |
will let the other, more technical, council members comment on that). |
53 |
There are still open questions on this here thread, there is a request |
54 |
for low-level documentation and a high-level doc is also required |
55 |
(make it a request from me if you want), a preliminary PMS patch is |
56 |
needed, possibly a devmanual patch too, etc... I'm not saying we're |
57 |
asking you to do all this alone because this isn't how a collaborative |
58 |
project like Gentoo should work. We have resources and they are at |
59 |
everybody's disposition. We (I) will help you coordinate that effort |
60 |
if you need/want it. |
61 |
|
62 |
I have noted somewhere that you are concerned about having to do an |
63 |
EAPI bump and were trying to work around that. I understand your |
64 |
concerns and would tend to agree with you since in the past these |
65 |
things were not addressed smoothly and timely enough. This council |
66 |
showed however that we were ready to change plans and create EAPI |
67 |
bumps when needed [1]. If multilib is ready before or at the same time |
68 |
as prefix we can add multilib to EAPI3. If not, well, we will bump as |
69 |
needed by multilib or any worthy project/enhancement anyway. There is |
70 |
no point carving (the former) EAPI3 into stone and having it block |
71 |
everything else due to its implementation taking longer than |
72 |
anticipated. |
73 |
|
74 |
Also, there is no good reason for doing things the wrong way. If an |
75 |
EAPI bump is needed for multilib then let's just do it. I will |
76 |
personally see to putting this EAPI bump on the agenda when multilib |
77 |
is ready. And I'm convinced that at that time my fellow council |
78 |
members will simply vote "yes". |
79 |
|
80 |
As you have noticed on the portage irc channel I discussed the |
81 |
maintenance of your branch with Zac. He has agreed to help you with |
82 |
that, and I understand that's your main concern at the moment. It |
83 |
appears that the portage repo is in the process of being converted to |
84 |
git [2] and this should make it a lot easier. I suggest you talk to |
85 |
Zac directly about this. Still on this subject, I will put the |
86 |
question of whether we should add this new multilib to the portage 2.2 |
87 |
branch or something more experimental on the agenda for the next |
88 |
meeting. I will also add multilib as a topic for the open floor |
89 |
discussion. |
90 |
|
91 |
Feel free to contact me in private if you have any question or need |
92 |
help with the above requests. I will do my best to assist you. |
93 |
|
94 |
Denis. |
95 |
|
96 |
[1] http://www.gentoo.org/proj/en/council/meeting-logs/20091207-summary.txt |
97 |
[2] https://bugs.gentoo.org/show_bug.cgi?id=196025#c34 and further |