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 1NOVal-00064U-Q7 for garchives@archives.gentoo.org; Sat, 26 Dec 2009 12:17:56 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6A8A4E0A9B for ; Sat, 26 Dec 2009 12:17:55 +0000 (UTC) Received: from amun.cheops.ods.org (amun.cheops.ods.org [82.95.138.191]) by pigeon.gentoo.org (Postfix) with ESMTP id 6B9A5E04C2 for ; Sat, 26 Dec 2009 10:25:37 +0000 (UTC) Received: from tefnut.cheops.ods.org ([2001:888:1022:0:211:24ff:fe37:e46e] helo=gentoo.org) by amun.cheops.ods.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71) (envelope-from ) id 1NOTq3-0004iD-HW for gentoo-dev@lists.gentoo.org; Sat, 26 Dec 2009 11:25:36 +0100 Date: Sat, 26 Dec 2009 11:25:00 +0100 From: Fabian Groffen To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date Message-ID: <20091226102500.GK1452@gentoo.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <7c612fc60912150854k608270cag61c533542075f5bf@mail.gmail.com> <4B2E2C59.3070004@gentoo.org> <7c612fc60912242110o32918b04t2e477a1573290a36@mail.gmail.com> <4B34C584.6070307@gentoo.org> 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4B34C584.6070307@gentoo.org> User-Agent: Mutt/1.5.20 (Darwin 8.11.0, VIM - Vi IMproved 7.2) Organization: Gentoo Foundation, Inc. X-Content-Scanned: by amun.cheops.ods.org (Exim Exiscan) using SpamAssassin and ClamAV X-Archives-Salt: b92718fb-af86-43c0-9f48-986bbd05f84c X-Archives-Hash: 68a2da3270e4d46a03696ce39e6d8117 Hi Thomas, On 25-12-2009 15:00:36 +0100, Thomas Sachau wrote: > On 12/25/2009 06:10 AM, Denis Dupeyron wrote: > > Sorry, I forgot to send an email explaining what happened on the > > council alias as promised. The consensus was that the project wasn't > > mature enough to go ahead. Also more generally the council's job isn't > > discussing but deciding, approving, etc... Discussing is what should > > happen on mailing lists. > > Since i see noone arguing against adding the multilib features to > current testing branch of portage, the discussion part already seems > to be done. so a simple approval is ok, drop the discussion request. This may be a wasted effort, but I tried figuring out what you do in your portage branch going by your earlier discussions. The idea I got is the following: Triggered by some mechanism (maybe unconditional), you just run each ebuild function executed by Portage multiple times, that is, for each ABI that you grab from somewhere. e.g: src_unpack() { for abi in ${EABIS} ; do mkdir ${WORKDIR}-${abi} cd ${WORKDIR}-${abi} unpack ${A} done } During configure you inject -m{32,64} in CFLAGS depending on your ABI. This gives your multilib-compiler the right hint to do the thing you want. This is about what I understood. Now here I have some questions that may or may not be relevant. What triggers a multilib build? Is it unconditional, or can it be turned on/off per package? How does Portage resolve/verify that a library is built for the right ABI in that case? Unpacking sources many times feels like a terrible waste to me, especially for things like GCC. If we would just start building outside of the workdir (sources) into a separate builddir, wouldn't that just be much cleaner and a nice EAPI feature? Since you make each compilation multiple times, you also obtain a fully identical installation of the same package. How do you deal with that? Do you have /usr/bin{64,32} directories for example too? If you only keep libs (found by a scanelf scan or something), how do you know what's relevant. Alternatively, if you build the full application anyway, isn't it a waste to throw away the result? You could see multilib also as two (unrelated) trees, such as e.g. a Gentoo Prefix installation. A nasty one: how to deal with libs that actually contain hardcoded paths to configuration from e.g. /etc or /var in your implementation? You chose to inject -m{32,64} in CFLAGS. Suppose you set CC to "gcc -m{32,64}" or even "x86_64-..." or "i686-..." you could do some cross-target stuff, I think. I say so in the light of Darwin systems which are capable of using Mach-O FAT objects. Such objects can contain multiple architectures. This idea is available for as FATelf also, and e.g. included in the zen-sources. On such system you ultimately want to handle the multilib hel^Wproblem by avoiding the different paths but instead generate that single unified tree that contains all your ABIs in each (FAT) file. Is your approach flexible enough to lipo two or more trees together in one after the two images are installed? > > Before you can bring that to the council we > > need to see an as-much-as-possible finalized solution with any of the > > following if applicable: portage branch with an implementation that > > people can try, documentation, PMS patch, devmanual patches, and a > > team. > > Did you actually read my lines? I did NOT request an ACK to add it to > PMS and next EAPI with a complete spec. zmedico also has no problem > with having a look and adding it, but since he was once forced to > remove an added feature, he now wants a council-ok before adding and > improving it in testing branch of main tree portage. >From my experience they just want to get some grip on the issue. A formal description helps sometimes. > > Look at what happened with prefix. They wanted > > the council to approve it immediately or else... We didn't cede to > > pressure and worked with them to make it good enough for approval. > > Something like "I/We want ,, or you wont get an approval" is > no support and no "work with them". So if you really would like to see > it in, actually help with patches, SPEC writing, discussion and code > writing. Else i request an approval for getting some additional help > instead of just shooting it down. Pfff, I guess like you, Thomas, we got a bit impatient. Our experience is that once you give the information to the council in the right format, they seem to be much more focussed. > > Right now I don't hear anybody arguing about prefix going forward. And > > that's exactly what I want for your project, i.e. helping you making > > it better instead of it fading and failing in the (not so) long run. > > prefix is no one-man-team and the actual amount of people, who can and > are willing to work on portage code is limited, so which other way do > you have to improve it as requested? Prefix has been more or less a one-man-team for a long long time, but then, the project exists for about 5 years now. I cannot really advise you to go that route, so please try to spec it. -- Fabian Groffen Gentoo on a different level