1 |
my mta is acting funny, i apologise if i end up sending this out twice... |
2 |
|
3 |
On Friday 23 April 2004 11:04 am, Paul Smith wrote: |
4 |
> What I want to be able to do is this: have one (or more) Portage |
5 |
> installations, or "images", on a system. An "image" is a complete |
6 |
> Portage system, but "virtualized" by having it rooted somewhere besides |
7 |
> /. Suppose you had a directory like /opt/portage, and under there you |
8 |
> had p1, p2, p3, etc. which were Portage images. Then underneath each |
9 |
> one of those would be, for example, an etc/portage directory, and a |
10 |
> var/log/emerge.log, and a var/db/pkg, etc. which contained Portage |
11 |
> control files/databases for only that image. |
12 |
|
13 |
*ears perk up* |
14 |
keep me posted on your success here. what i would like to do with portage |
15 |
varies greatly from what you seem to want, but it depends on the exact same |
16 |
functionality, with slightly different limitations. |
17 |
|
18 |
what /i/ would love to see in portage is true multilib compatibility for |
19 |
archs with a bi-arch toolchain, with seperate dependency trees for each |
20 |
bitdepth that is supported. in the case of amd64, that would mean seperate |
21 |
dependency trees for 64bit and 32bit. |
22 |
|
23 |
right now, on amd64, we are as non-compliant as it can get in regards to |
24 |
standards and it makes quite a few things difficult sometimes... but a lot of |
25 |
things want to install to lib and not lib64, and nobody really wants to |
26 |
bother rewriting econf as well as any ebuild that doesn't use it when we dont |
27 |
even have support for the multiple dependency trees that would justify such |
28 |
work. |
29 |
|
30 |
another oddity brought on by the bi-arch toolchain problem that would |
31 |
complicate things even more is that unlike your cross-compiler case, in a |
32 |
multilib situation you would need cross-tree dependencies and everything from |
33 |
both trees will be installed to the same ROOT, using the same BUILDROOT. so |
34 |
this part of your work probably wont help the multilib case (dont mind me, |
35 |
i'm not a python coder and i'm already thinking about how to hack whatever |
36 |
you end up working on to do what i want it to ^_^ ). we would need to have |
37 |
only one gcc, glibc, etc... and it would have to be 64bit on amd64. on amd64, |
38 |
the 64bit toolchain would need to be used to build anything in the 32bit dep |
39 |
tree, only with the forced addition of -m32 everywhere. |
40 |
|
41 |
> Now when you want to install a new package, before you can run emerge |
42 |
> you need to choose a "build", or host, image and a "destination", or |
43 |
> target, image. We'll say that the destination is selected by the value |
44 |
> of ROOT, and the build image is selected by the value of BUILDROOT. |
45 |
|
46 |
i can also see any work you do here helping out in the multilib case, if it's |
47 |
taken into account. however, instead of ROOT and BUILDROOT there would have |
48 |
to be a way to handle ROOTARCH and BUILDROOTARCH, or something similar... in |
49 |
the multilib case, at least for amd64, we would want 32bit libraries to end |
50 |
up in /lib, and 32bit binaries to have the suffix "32". and the binary |
51 |
package itself would have to decide it's own arch... there would be no other |
52 |
way of knowing what the package contains without unpacking it. and then we |
53 |
wouldn't know if the package doesn't contain anything arch-specific we could |
54 |
test... hmm. |
55 |
|
56 |
> Obviously the simplest case is where both ROOT and BUILDROOT are "/" |
57 |
> (which would be the default value). This represents the standard |
58 |
> Portage usage. |
59 |
|
60 |
for the multilib case, this is anything but simple :'( |
61 |
|
62 |
> The idea is you could create new Portage images quite independently from |
63 |
> your real system. In particular, the new Portage image could be for a |
64 |
> completely different architecture: cross-compilers could be installed in |
65 |
> the "build" image, then used to build and install into the |
66 |
> "destination". |
67 |
|
68 |
i'm much more interested in the ability to use the amd64 native 64bit |
69 |
toolchain to build 64bit, 32bit, and bi-arch installs without use of a |
70 |
cross-compiler or having to drop into a 32bit chroot. :) |
71 |
|
72 |
> The above is not such a big deal; it could play relatively nicely I |
73 |
> think with the current Portage. We just need to change references to |
74 |
> fully-qualified paths with variable-qualified paths based on the |
75 |
> BUILDROOT value. |
76 |
|
77 |
for the multilib case we would need additional variables to decide where |
78 |
things go, and such. :/ |
79 |
|
80 |
> However, the problem of the current handling of DEPEND vs. RDEPEND is |
81 |
> not so simple to resolve. It looks like DEPEND and RDEPEND are targeted |
82 |
> at a very different scenario than the one I outline above. If ROOT is |
83 |
> set, it appears that Portage looks for DEPEND packages on the "real" |
84 |
> system and RDEPEND packages in the ROOT image. Also, all the Portage |
85 |
> database info, logs, etc. is kept in the "real" root, not the ROOT root. |
86 |
> I guess I'm not quite clear on what scenario this setup actually |
87 |
> supports? Can anyone give me a quick use-case? It almost seems like |
88 |
> you're trying to support creating non-Portage-based images from a |
89 |
> Portage-based image... that's not something I'm really that interested |
90 |
> in. |
91 |
|
92 |
multilib will probably also require an arch-less or arch-of-choice dependency |
93 |
that specifies when a package could really care less what arch the dependency |
94 |
is. scripts and interpreted languages dont give a damn what arch the shell |
95 |
and interpreter are, for example. also, for a functional install, a multilib |
96 |
system probably doesnt want two seperate copies of certain things installed |
97 |
to ROOT... i'm pretty sure we only need one kernel logger, init, bash, etc. |
98 |
i'd say most if not all of what would appear in a stage3 that isn't a library |
99 |
(or glibc, which is multilib aware and will install as 32bit and 64bit if |
100 |
told to). |
101 |
|
102 |
so, also, three dependency trees... where the two bi-arch trees include deps |
103 |
from a third tree containing stuff that shouldn't be installed twice? *shrug* |
104 |
|
105 |
> In my environment the above would not be correct: both DEPEND and |
106 |
> RDEPEND packages would have to appear in the ROOT image (remember that |
107 |
> the BUILDROOT and ROOT could be completely different architectures!) |
108 |
|
109 |
ditto. kinda. |
110 |
|
111 |
> SO! Does any of that make sense? Is there some way we can rationalize |
112 |
> the handling of DEPEND/RDEPEND? Maybe something like if BUILDROOT is |
113 |
> set then DEPEND/RDEPEND are both looked for in the ROOT? I don't really |
114 |
> like that as it seems like "special magic" that's kind of difficult to |
115 |
> understand, but it is backward-compatible. |
116 |
|
117 |
i'm thinking that if you take into consideration just cross-compiling, there |
118 |
would have to be additional hacks added later on if portage ever wants to |
119 |
support multilib. but if you take multilib into consideration just a little |
120 |
while working on cross-compiling, we might end up getting multilib support |
121 |
almost for free. and if that happens, dude i will love you for LIFE. |
122 |
|
123 |
you have no idea how much of a PITA it is to support 32bit anything in |
124 |
gentoo. if we were multilib compliant, you could almost install packages |
125 |
from x86 gentoo on amd64 without modification. all we would need is some |
126 |
editing to the ebuild install to rename 32bit apps, perhaps rename env.d |
127 |
entries, perhaps add a script in post-install for the real name that will |
128 |
run the 32bit version... etc. similar workarounds could be provided for |
129 |
64bit installs to make sure that /all/ 64bit libs end up in a lib64 |
130 |
directory... |
131 |
|
132 |
hmm. yeah. dont mind me for thinking out loud to the list, but it would |
133 |
definately make me VERY happy to see such functionality in portage. you have |
134 |
no idea... even after all the work it would take to work around the current |
135 |
UGLY FREAKING HACKS we use and any additional work needed to provide |
136 |
compatibility/migration for our current hacked-as-fsck ugly-as-sin installs. |
137 |
|
138 |
|
139 |
Travis Tilley <lv@g.o> |
140 |
Gentoo/AMD64 Developer |
141 |
|
142 |
-- |
143 |
gentoo-dev@g.o mailing list |