Gentoo Archives: gentoo-alt

From: Markus Duft <mduft@g.o>
To: gentoo-alt@l.g.o
Subject: [gentoo-alt] prefix-chaining
Date: Mon, 23 Mar 2009 15:40:55
Message-Id: 1237821875.3020.33.camel@localhost
1 Hi,
2
3 It's me again talking about cross-prefix/prefix-chaining. the current
4 cross-prefix patch is mostly unmaintainable right now, sinec it's just
5 too big. so i decided to try a new approach, which patches portage to be
6 able to read the var/db/* tree of other portage instances, and take
7 configured dependency types from there.
8
9 what i mean is, that in etc/make.conf for one prefix installation i can
10 do something like "READONLY_EROOT=/some/other/prefix:DEPEND" or even
11 "READONLY_EROOT=/some/other/prefix/with/the/same/CHOST:DEPEND,RDEPEND",
12 which will enable the prefix with this make.conf ro resolve any DEPEND
13 atom from the installed tree of that prefix.
14
15 of course i'm aware that this _might_ break things, if somebody decides
16 to unmerge packages from /some/other/prefix, but i guess there is no way
17 around that right now.
18
19 I need to create a chained-prefix-setup package or something like that,
20 and toolchain wrappers, but that's the next step after the portage patch
21 is done... (maybe i'll patch baselayout-prefix?)
22
23 i'll summarize the changes i have done:
24
25 _emerge/__init__.py:
26 * for correct readonly resolving, i need to know which kind
27 of DEPEND/RDEPEND/PDEPEND i'm working on. this is why i
28 need to memorize them as dep_type, and pass it through to
29 the readonly resolver functions.
30 the rest of the behaviour is exactly the same as before, so
31 this has absolutely no influence on functionality.
32 * i'm setting disp_parent on trees[root], since parent can
33 be None, and i want a consistent display of readonly packages
34 in the final merge list.
35 as before, this does not change behaviour in any way.
36 * when displaying the merge list, i'm now also displaying a
37 list of readonly packages, selected from another portage
38 instance's var/db tree.
39 this also has no effect on portage's behaviour
40
41 portage/__init__.py:
42 * i added code to memorize and parse readonly EROOT's from
43 make.conf, recursing into readonly prefixes. this means that
44 one can build a chain of prefixes (thus prefix chaining).
45 this keeps going as long as a make.conf it find's contains
46 a READONLY_EROOT line.
47 This still does not change portage's behaviour.
48 There is one pitfall here: for example think of this setup:
49 /my/prefix/etc/make.conf:
50 READONLY_EROOT=/my/parent/prefix:DEPEND
51 /my/parent/prefix/etc/make.conf:
52 READONLY_EROOT=/my/pp/prefix:DEPEN,RDEPEND
53 This will cause /my/prefix to resolve RDEPEND's from
54 /my/pp/prefix! this needs to be discussed, wether this is
55 ok, or wether only DEPEND's should be resolved, since from
56 /my/parent/prefix only DEPEND's are allowed.
57 * i added the logic for really reading the chained var/db trees
58 and resolving dependencies from there. this is two functions,
59 which on their own of course don't change portage's behaviour.
60 * i had to add the dep_type argument to the dep_check function
61 to be able to do correct readonly resolving. this on it's own
62 doesn't change anything, since there is a default value, so
63 any existing unmodified call will still work.
64 * if the dep_type is set (which should be the case during
65 relevant parts of dependency resolving), the only change thet
66 influences portage's behaviour comes into play: a call to the
67 readonly dependency resolving algorithm. this works by marking
68 packages as provided, just as if they where specified in
69 package.provided.
70
71 portage/dbapi/vartree.py:
72 * the vartree class is used for readonly dependency resolution,
73 just as with the normal "local" var/db. this means i have to
74 somehow avoid EPREFIX beeing added to all the paths, since i
75 want to have only the path to the chained parent.
76 this is only in effect if the vartree is constructed with
77 kill_eprefix=True, which is only the case for readonly
78 vartrees, so it does not influence the rest of portage in
79 any way.
80
81 so far, so good. i hope i got all changes :)
82
83 BTW.: this enables a prefixed portage instance to resolve DEPENDS (or
84 anything you like) from /. this means on gentoo linux, most packages
85 could be taken from / and a prefix installation akts like an "extension"
86 to it. as i said above i still have to figure out the baselayout and
87 toolchain wrapper stuff :)
88
89 questions/comments?
90
91 Cheers, Markus

Attachments

File name MIME type
portage-chaining-8.patch text/x-patch

Replies

Subject Author
Re: [gentoo-alt] prefix-chaining Fabian Groffen <grobian@g.o>