1 |
On 23-03-2009 16:24:35 +0100, Markus Duft wrote: |
2 |
> Hi, |
3 |
> |
4 |
> It's me again talking about cross-prefix/prefix-chaining. the current |
5 |
> cross-prefix patch is mostly unmaintainable right now, sinec it's just |
6 |
> too big. so i decided to try a new approach, which patches portage to be |
7 |
> able to read the var/db/* tree of other portage instances, and take |
8 |
> configured dependency types from there. |
9 |
> |
10 |
> what i mean is, that in etc/make.conf for one prefix installation i can |
11 |
> do something like "READONLY_EROOT=/some/other/prefix:DEPEND" or even |
12 |
> "READONLY_EROOT=/some/other/prefix/with/the/same/CHOST:DEPEND,RDEPEND", |
13 |
> which will enable the prefix with this make.conf ro resolve any DEPEND |
14 |
> atom from the installed tree of that prefix. |
15 |
|
16 |
I don't understand what this is exactly necessary for. Can you give the |
17 |
use-case scenario and how it solves what problem? |
18 |
|
19 |
> of course i'm aware that this _might_ break things, if somebody decides |
20 |
> to unmerge packages from /some/other/prefix, but i guess there is no way |
21 |
> around that right now. |
22 |
|
23 |
sofar it sounds extremely hackish |
24 |
|
25 |
> I need to create a chained-prefix-setup package or something like that, |
26 |
> and toolchain wrappers, but that's the next step after the portage patch |
27 |
> is done... (maybe i'll patch baselayout-prefix?) |
28 |
|
29 |
-#!@GENTOO_PORTAGE_EPREFIX@/bin/bash |
30 |
+#!/usr/bin/env bash |
31 |
|
32 |
why is that necessary to be changed in gcc-config? |
33 |
|
34 |
> i'll summarize the changes i have done: |
35 |
> |
36 |
> _emerge/__init__.py: |
37 |
> * for correct readonly resolving, i need to know which kind |
38 |
> of DEPEND/RDEPEND/PDEPEND i'm working on. this is why i |
39 |
> need to memorize them as dep_type, and pass it through to |
40 |
> the readonly resolver functions. |
41 |
> the rest of the behaviour is exactly the same as before, so |
42 |
> this has absolutely no influence on functionality. |
43 |
> * i'm setting disp_parent on trees[root], since parent can |
44 |
> be None, and i want a consistent display of readonly packages |
45 |
> in the final merge list. |
46 |
> as before, this does not change behaviour in any way. |
47 |
> * when displaying the merge list, i'm now also displaying a |
48 |
> list of readonly packages, selected from another portage |
49 |
> instance's var/db tree. |
50 |
> this also has no effect on portage's behaviour |
51 |
> |
52 |
> portage/__init__.py: |
53 |
> * i added code to memorize and parse readonly EROOT's from |
54 |
> make.conf, recursing into readonly prefixes. this means that |
55 |
> one can build a chain of prefixes (thus prefix chaining). |
56 |
> this keeps going as long as a make.conf it find's contains |
57 |
> a READONLY_EROOT line. |
58 |
> This still does not change portage's behaviour. |
59 |
> There is one pitfall here: for example think of this setup: |
60 |
> /my/prefix/etc/make.conf: |
61 |
> READONLY_EROOT=/my/parent/prefix:DEPEND |
62 |
> /my/parent/prefix/etc/make.conf: |
63 |
> READONLY_EROOT=/my/pp/prefix:DEPEN,RDEPEND |
64 |
> This will cause /my/prefix to resolve RDEPEND's from |
65 |
> /my/pp/prefix! this needs to be discussed, wether this is |
66 |
> ok, or wether only DEPEND's should be resolved, since from |
67 |
> /my/parent/prefix only DEPEND's are allowed. |
68 |
|
69 |
For that it must be clear first what the objective of this all is. |
70 |
Also, have you talked to solar, slomosomething and sleipir? They are |
71 |
working on a thing for cross-compiling, where this might come close to. |
72 |
|
73 |
> * i added the logic for really reading the chained var/db trees |
74 |
> and resolving dependencies from there. this is two functions, |
75 |
> which on their own of course don't change portage's behaviour. |
76 |
> * i had to add the dep_type argument to the dep_check function |
77 |
> to be able to do correct readonly resolving. this on it's own |
78 |
> doesn't change anything, since there is a default value, so |
79 |
> any existing unmodified call will still work. |
80 |
> * if the dep_type is set (which should be the case during |
81 |
> relevant parts of dependency resolving), the only change thet |
82 |
> influences portage's behaviour comes into play: a call to the |
83 |
> readonly dependency resolving algorithm. this works by marking |
84 |
> packages as provided, just as if they where specified in |
85 |
> package.provided. |
86 |
> |
87 |
> portage/dbapi/vartree.py: |
88 |
> * the vartree class is used for readonly dependency resolution, |
89 |
> just as with the normal "local" var/db. this means i have to |
90 |
> somehow avoid EPREFIX beeing added to all the paths, since i |
91 |
> want to have only the path to the chained parent. |
92 |
> this is only in effect if the vartree is constructed with |
93 |
> kill_eprefix=True, which is only the case for readonly |
94 |
> vartrees, so it does not influence the rest of portage in |
95 |
> any way. |
96 |
|
97 |
sounds like there should be a better way to set eprefix then, because |
98 |
killing a prefix is sort of a fixed case of an eprefix change, and makes |
99 |
it only useful with a Gentoo host. |
100 |
|
101 |
> so far, so good. i hope i got all changes :) |
102 |
> |
103 |
> BTW.: this enables a prefixed portage instance to resolve DEPENDS (or |
104 |
> anything you like) from /. this means on gentoo linux, most packages |
105 |
> could be taken from / and a prefix installation akts like an "extension" |
106 |
> to it. as i said above i still have to figure out the baselayout and |
107 |
> toolchain wrapper stuff :) |
108 |
> |
109 |
> questions/comments? |
110 |
|
111 |
hmmm, yeah. You are not going to tell me you did all of this just |
112 |
because you want to reuse stuff from an Gentoo Linux host, do you? That |
113 |
sounds like an extreme corner-case to me. |
114 |
|
115 |
|
116 |
|
117 |
-- |
118 |
Fabian Groffen |
119 |
Gentoo on a different level |