[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting
From:       Fabian Groffen <grobian () gentoo ! org>
Date:       2009-12-26 10:25:00
Message-ID: 20091226102500.GK1452 () gentoo ! org
[Download RAW message or body]

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 <x>,<y>,<z> 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

[prev in list] [next in list] [prev in thread] [next in thread]