From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NWkgu-0000yK-Kt for garchives@archives.gentoo.org; Mon, 18 Jan 2010 06:02:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E328CE0856; Mon, 18 Jan 2010 06:01:59 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id A17AEE08C0 for ; Mon, 18 Jan 2010 06:01:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 1635F67ED5 for ; Mon, 18 Jan 2010 06:01:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 required=5.5 tests=[AWL=0.614, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+-A8dHDeWuD for ; Mon, 18 Jan 2010 06:01:48 +0000 (UTC) Received: from mail-ew0-f223.google.com (mail-ew0-f223.google.com [209.85.219.223]) by smtp.gentoo.org (Postfix) with ESMTP id 37A5B679C1 for ; Mon, 18 Jan 2010 06:01:47 +0000 (UTC) Received: by ewy23 with SMTP id 23so1517307ewy.24 for ; Sun, 17 Jan 2010 22:01:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=7vzK0/QAtNscXJmpWoDFlBqCQyYsIYxOArVX0w2MacM=; b=DNN2BLY/AG8kxo0HOlSrYY5fYJOVZdWY2xtFlnz8duD5oBrfUiKurO0zql2E7LZcRn nxeWvNmHAydmpKNLbdUEJ9SKkH+mLNrQ5J9LHt5eltJGQF5MQK7upLaMbibcFWSFQ+AH 4Om5ruZFI8iZ0KA+rvjmc3K4hNWhR9dRgX0oM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=hhZLEma5DsAvsVl8UOVK0Uq10TXkSXsRYFaoJCOMAdIGl23Y0luiddi+QSdpGumHba itG3DnFdqG8dLBn+SL6JMoa/a9i6e7bgkUYCmgo25E65gTaymOgS4rUO49RD/pN3OdrA i4oBTTou6lCnAcoqqSRIxQk/iY0n/OzwTX4Go= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Sender: denis.dupeyron@gmail.com Received: by 10.216.87.14 with SMTP id x14mr1981884wee.127.1263794498255; Sun, 17 Jan 2010 22:01:38 -0800 (PST) In-Reply-To: <4A87FD91.20406@gentoo.org> References: <4A87FD91.20406@gentoo.org> Date: Sun, 17 Jan 2010 23:01:38 -0700 X-Google-Sender-Auth: 080c55de128d5583 Message-ID: <7c612fc61001172201g418c5b8xc003c314ee09013d@mail.gmail.com> Subject: Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay From: Denis Dupeyron To: gentoo-dev Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: c4758d20-1346-4859-8866-b9282a4d6189 X-Archives-Hash: 948660df66caf822776b8f2bd0d82b57 (I'm resending this email as the original apparently did not make it to the list, although Thomas probably received it) Hi Thomas, I'm replying to the original thread below to allow those who have missed it to have the full context. On Sun, Aug 16, 2009 at 5:37 AM, Thomas Sachau wrote: > Let me introduce a nice project, which was started by some users: > > Since the emul-linux-x86-* packages for 32bit libs for amd64 users are neither easy to maintain nor > up-to-date, some users started to implement an eclass, which allows to build requested libs with > additional 32bit support. Later i joined them and helped them improving it a bit, but it was and > still is mainly their project, they do the main work keeping this overlay up-to-date. > > Also this overlay is a nice idea to drop emul-linux-x86-* packages, it either requires continual > work or modification of many ebuilds in main tree to support this in long term. To avoid this, i > took the original multilib portage patch from kanaka, adjusted it to the current portage code and > added the ideas and code from the eclass version. The result is now a portage, which is able to > build any ebuild with additional 32bit lib support. > > The current main regression are ebuilds and eclasses, which do not support this (e.g. perl modules > and mysql). > > If anyone is interested: > > -for the eclass version, which is mainly maintained by users and is mainly intended to only replace > the emul-linux-x86-* package: just add it via "layman -a multilib" (it should be pretty stable and > mostly working). > > -for the portage version: It is also in the multilib overlay, but in a different branch called > portage-multilib. To use this, you should read the instructions at [1] > (doc/portage-multilib-instructions). This one should also mainly work, but there is probably a good > amount of packages in the main tree, which may refuse to work with it. > > Bugreports: preferred way is #gentoo-multilib-overlay at irc.freenode.org, but we also have an > alias, where you can contact us: multilib@g.o > > [1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib > -- > Thomas Sachau > > Gentoo Linux Developer I have already explained that I think it's a wonderful project and I definitely would like to see it in the tree sooner rather than later. There was a discussion on the council alias where everybody who participated seemed to like it too. However the consensus was that the project wasn't mature enough (I will let the other, more technical, council members comment on that). There are still open questions on this here thread, there is a request for low-level documentation and a high-level doc is also required (make it a request from me if you want), a preliminary PMS patch is needed, possibly a devmanual patch too, etc... I'm not saying we're asking you to do all this alone because this isn't how a collaborative project like Gentoo should work. We have resources and they are at everybody's disposition. We (I) will help you coordinate that effort if you need/want it. I have noted somewhere that you are concerned about having to do an EAPI bump and were trying to work around that. I understand your concerns and would tend to agree with you since in the past these things were not addressed smoothly and timely enough. This council showed however that we were ready to change plans and create EAPI bumps when needed [1]. If multilib is ready before or at the same time as prefix we can add multilib to EAPI3. If not, well, we will bump as needed by multilib or any worthy project/enhancement anyway. There is no point carving (the former) EAPI3 into stone and having it block everything else due to its implementation taking longer than anticipated. Also, there is no good reason for doing things the wrong way. If an EAPI bump is needed for multilib then let's just do it. I will personally see to putting this EAPI bump on the agenda when multilib is ready. And I'm convinced that at that time my fellow council members will simply vote "yes". As you have noticed on the portage irc channel I discussed the maintenance of your branch with Zac. He has agreed to help you with that, and I understand that's your main concern at the moment. It appears that the portage repo is in the process of being converted to git [2] and this should make it a lot easier. I suggest you talk to Zac directly about this. Still on this subject, I will put the question of whether we should add this new multilib to the portage 2.2 branch or something more experimental on the agenda for the next meeting. I will also add multilib as a topic for the open floor discussion. Feel free to contact me in private if you have any question or need help with the above requests. I will do my best to assist you. Denis. [1] http://www.gentoo.org/proj/en/council/meeting-logs/20091207-summary.txt [2] https://bugs.gentoo.org/show_bug.cgi?id=196025#c34 and further