Gentoo Archives: gentoo-alt

From: Fabian Groffen <grobian@g.o>
To: gentoo-alt@l.g.o
Subject: Re: [gentoo-alt] prefix-chaining
Date: Wed, 25 Mar 2009 10:36:47
Message-Id: 20090325103639.GF12431@gentoo.org
In Reply to: [gentoo-alt] prefix-chaining by Markus Duft
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

Replies

Subject Author
Re: [gentoo-alt] prefix-chaining Markus Duft <mduft@g.o>