Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-alt
Navigation:
Lists: gentoo-alt: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-alt@g.o
From: Fabian Groffen <grobian@g.o>
Subject: Re: prefix-chaining
Date: Wed, 25 Mar 2009 11:36:39 +0100
On 23-03-2009 16:24:35 +0100, Markus Duft wrote:
> Hi,
> 
> It's me again talking about cross-prefix/prefix-chaining. the current
> cross-prefix patch is mostly unmaintainable right now, sinec it's just
> too big. so i decided to try a new approach, which patches portage to be
> able to read the var/db/* tree of other portage instances, and take
> configured dependency types from there.
> 
> what i mean is, that in etc/make.conf for one prefix installation i can
> do something like "READONLY_EROOT=/some/other/prefix:DEPEND" or even
> "READONLY_EROOT=/some/other/prefix/with/the/same/CHOST:DEPEND,RDEPEND",
> which will enable the prefix with this make.conf ro resolve any DEPEND
> atom from the installed tree of that prefix.

I don't understand what this is exactly necessary for.  Can you give the
use-case scenario and how it solves what problem?

> of course i'm aware that this _might_ break things, if somebody decides
> to unmerge packages from /some/other/prefix, but i guess there is no way
> around that right now.

sofar it sounds extremely hackish

> I need to create a chained-prefix-setup package or something like that,
> and toolchain wrappers, but that's the next step after the portage patch
> is done... (maybe i'll patch baselayout-prefix?)

-#!@GENTOO_PORTAGE_EPREFIX@/bin/bash
+#!/usr/bin/env bash

why is that necessary to be changed in gcc-config?

> i'll summarize the changes i have done:
> 
> _emerge/__init__.py:
> 	* for correct readonly resolving, i need to know which kind
> 	  of DEPEND/RDEPEND/PDEPEND i'm working on. this is why i
> 	  need to memorize them as dep_type, and pass it through to
> 	  the readonly resolver functions.
> 	  the rest of the behaviour is exactly the same as before, so
> 	  this has absolutely no influence on functionality.
> 	* i'm setting disp_parent on trees[root], since parent can
> 	  be None, and i want a consistent display of readonly packages
> 	  in the final merge list.
> 	  as before, this does not change behaviour in any way.
> 	* when displaying the merge list, i'm now also displaying a
> 	  list of readonly packages, selected from another portage
> 	  instance's var/db tree.
> 	  this also has no effect on portage's behaviour
> 
> portage/__init__.py:
> 	* i added code to memorize and parse readonly EROOT's from
> 	  make.conf, recursing into readonly prefixes. this means that
> 	  one can build a chain of prefixes (thus prefix chaining).
> 	  this keeps going as long as a make.conf it find's contains
> 	  a READONLY_EROOT line.
> 	  This still does not change portage's behaviour.
> 	  There is one pitfall here: for example think of this setup:
> 		/my/prefix/etc/make.conf:
> 			READONLY_EROOT=/my/parent/prefix:DEPEND
> 		/my/parent/prefix/etc/make.conf:
> 			READONLY_EROOT=/my/pp/prefix:DEPEN,RDEPEND
> 	  This will cause /my/prefix to resolve RDEPEND's from
> 	  /my/pp/prefix! this needs to be discussed, wether this is
> 	  ok, or wether only DEPEND's should be resolved, since from
> 	  /my/parent/prefix only DEPEND's are allowed.

For that it must be clear first what the objective of this all is.
Also, have you talked to solar, slomosomething and sleipir?  They are
working on a thing for cross-compiling, where this might come close to.

> 	* i added the logic for really reading the chained var/db trees
> 	  and resolving dependencies from there. this is two functions,
> 	  which on their own of course don't change portage's behaviour.
> 	* i had to add the dep_type argument to the dep_check function
> 	  to be able to do correct readonly resolving. this on it's own
> 	  doesn't change anything, since there is a default value, so
> 	  any existing unmodified call will still work.
> 	* if the dep_type is set (which should be the case during
> 	  relevant parts of dependency resolving), the only change thet
> 	  influences portage's behaviour comes into play: a call to the
> 	  readonly dependency resolving algorithm. this works by marking
> 	  packages as provided, just as if they where specified in
> 	  package.provided.
> 
> portage/dbapi/vartree.py:
> 	* the vartree class is used for readonly dependency resolution,
> 	  just as with the normal "local" var/db. this means i have to
> 	  somehow avoid EPREFIX beeing added to all the paths, since i
> 	  want to have only the path to the chained parent.
> 	  this is only in effect if the vartree is constructed with
> 	  kill_eprefix=True, which is only the case for readonly
> 	  vartrees, so it does not influence the rest of portage in 
> 	  any way.

sounds like there should be a better way to set eprefix then, because
killing a prefix is sort of a fixed case of an eprefix change, and makes
it only useful with a Gentoo host.

> so far, so good. i hope i got all changes :)
> 
> BTW.: this enables a prefixed portage instance to resolve DEPENDS (or
> anything you like) from /. this means on gentoo linux, most packages
> could be taken from / and a prefix installation akts like an "extension"
> to it. as i said above i still have to figure out the baselayout and
> toolchain wrapper stuff :)
> 
> questions/comments?

hmmm, yeah.  You are not going to tell me you did all of this just
because you want to reuse stuff from an Gentoo Linux host, do you?  That
sounds like an extreme corner-case to me.



-- 
Fabian Groffen
Gentoo on a different level


Replies:
Re: prefix-chaining
-- Markus Duft
References:
prefix-chaining
-- Markus Duft
Navigation:
Lists: gentoo-alt: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
prefix-chaining
Next by thread:
Re: prefix-chaining
Previous by date:
Re: [PREFIX] prefix keywords need to go (?)
Next by date:
Re: prefix chaining


Updated Jun 17, 2009

Summary: Archive of the gentoo-alt mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.