1 |
Hi Thomas, |
2 |
|
3 |
On 25-12-2009 15:00:36 +0100, Thomas Sachau wrote: |
4 |
> On 12/25/2009 06:10 AM, Denis Dupeyron wrote: |
5 |
> > Sorry, I forgot to send an email explaining what happened on the |
6 |
> > council alias as promised. The consensus was that the project wasn't |
7 |
> > mature enough to go ahead. Also more generally the council's job isn't |
8 |
> > discussing but deciding, approving, etc... Discussing is what should |
9 |
> > happen on mailing lists. |
10 |
> |
11 |
> Since i see noone arguing against adding the multilib features to |
12 |
> current testing branch of portage, the discussion part already seems |
13 |
> to be done. so a simple approval is ok, drop the discussion request. |
14 |
|
15 |
This may be a wasted effort, but I tried figuring out what you do in |
16 |
your portage branch going by your earlier discussions. The idea I got |
17 |
is the following: |
18 |
|
19 |
Triggered by some mechanism (maybe unconditional), you just run each |
20 |
ebuild function executed by Portage multiple times, that is, for each |
21 |
ABI that you grab from somewhere. e.g: |
22 |
src_unpack() { |
23 |
for abi in ${EABIS} ; do |
24 |
mkdir ${WORKDIR}-${abi} |
25 |
cd ${WORKDIR}-${abi} |
26 |
unpack ${A} |
27 |
done |
28 |
} |
29 |
|
30 |
During configure you inject -m{32,64} in CFLAGS depending on your ABI. |
31 |
This gives your multilib-compiler the right hint to do the thing you |
32 |
want. |
33 |
|
34 |
This is about what I understood. Now here I have some questions that |
35 |
may or may not be relevant. |
36 |
|
37 |
What triggers a multilib build? Is it unconditional, or can it be |
38 |
turned on/off per package? How does Portage resolve/verify that a |
39 |
library is built for the right ABI in that case? |
40 |
|
41 |
Unpacking sources many times feels like a terrible waste to me, |
42 |
especially for things like GCC. If we would just start building outside |
43 |
of the workdir (sources) into a separate builddir, wouldn't that just |
44 |
be much cleaner and a nice EAPI feature? |
45 |
|
46 |
Since you make each compilation multiple times, you also obtain a fully |
47 |
identical installation of the same package. How do you deal with that? |
48 |
Do you have /usr/bin{64,32} directories for example too? If you only |
49 |
keep libs (found by a scanelf scan or something), how do you know what's |
50 |
relevant. Alternatively, if you build the full application anyway, |
51 |
isn't it a waste to throw away the result? You could see multilib also |
52 |
as two (unrelated) trees, such as e.g. a Gentoo Prefix installation. |
53 |
A nasty one: how to deal with libs that actually contain hardcoded paths |
54 |
to configuration from e.g. /etc or /var in your implementation? |
55 |
|
56 |
You chose to inject -m{32,64} in CFLAGS. Suppose you set CC to "gcc |
57 |
-m{32,64}" or even "x86_64-..." or "i686-..." you could do some |
58 |
cross-target stuff, I think. I say so in the light of Darwin systems |
59 |
which are capable of using Mach-O FAT objects. Such objects can contain |
60 |
multiple architectures. This idea is available for as FATelf also, and |
61 |
e.g. included in the zen-sources. On such system you ultimately want to |
62 |
handle the multilib hel^Wproblem by avoiding the different paths but |
63 |
instead generate that single unified tree that contains all your ABIs in |
64 |
each (FAT) file. Is your approach flexible enough to lipo two or more |
65 |
trees together in one after the two images are installed? |
66 |
|
67 |
> > Before you can bring that to the council we |
68 |
> > need to see an as-much-as-possible finalized solution with any of the |
69 |
> > following if applicable: portage branch with an implementation that |
70 |
> > people can try, documentation, PMS patch, devmanual patches, and a |
71 |
> > team. |
72 |
> |
73 |
> Did you actually read my lines? I did NOT request an ACK to add it to |
74 |
> PMS and next EAPI with a complete spec. zmedico also has no problem |
75 |
> with having a look and adding it, but since he was once forced to |
76 |
> remove an added feature, he now wants a council-ok before adding and |
77 |
> improving it in testing branch of main tree portage. |
78 |
|
79 |
From my experience they just want to get some grip on the issue. A |
80 |
formal description helps sometimes. |
81 |
|
82 |
> > Look at what happened with prefix. They wanted |
83 |
> > the council to approve it immediately or else... We didn't cede to |
84 |
> > pressure and worked with them to make it good enough for approval. |
85 |
> |
86 |
> Something like "I/We want <x>,<y>,<z> or you wont get an approval" is |
87 |
> no support and no "work with them". So if you really would like to see |
88 |
> it in, actually help with patches, SPEC writing, discussion and code |
89 |
> writing. Else i request an approval for getting some additional help |
90 |
> instead of just shooting it down. |
91 |
|
92 |
Pfff, I guess like you, Thomas, we got a bit impatient. Our experience |
93 |
is that once you give the information to the council in the right |
94 |
format, they seem to be much more focussed. |
95 |
|
96 |
> > Right now I don't hear anybody arguing about prefix going forward. And |
97 |
> > that's exactly what I want for your project, i.e. helping you making |
98 |
> > it better instead of it fading and failing in the (not so) long run. |
99 |
> |
100 |
> prefix is no one-man-team and the actual amount of people, who can and |
101 |
> are willing to work on portage code is limited, so which other way do |
102 |
> you have to improve it as requested? |
103 |
|
104 |
Prefix has been more or less a one-man-team for a long long time, but |
105 |
then, the project exists for about 5 years now. I cannot really advise |
106 |
you to go that route, so please try to spec it. |
107 |
|
108 |
|
109 |
-- |
110 |
Fabian Groffen |
111 |
Gentoo on a different level |