Gentoo Archives: gentoo-dev

From: Denis Dupeyron <calchan@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay
Date: Mon, 18 Jan 2010 06:02:20
Message-Id: 7c612fc61001172201g418c5b8xc003c314ee09013d@mail.gmail.com
In Reply to: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay by Thomas Sachau
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