[gentoo-portage-dev] ia64 rpaths and python building...
Hey!
I recently did some ia64-hpux hacking in prefix, and i stumbled over
alittle problem:
the native linker collects -L options on the command line, and python
uses -L. while building. this results in . beeing in rpath.
now when $PWD == $S, there is libpython-*.so, and executing the already
installed python finds (through rpath .) this local libpython. this
(although binary exactly the same) refuses to load installed extensions
(Fatal Python Error: ).
The problem was caused by the filter-bash-environment.py call in
ebuild.sh, _only_ during the test phase seemingly.
the attached patch fixes the problem for me - what do you think? I guess
there are better ways to tackle the problem, but i needed to get this to
work ;)
Cheers, Markus
Only in portage.orig/bin: .ebuild.sh.swp
diff -ru portage.orig/bin/ebuild.sh portage/bin/ebuild.sh
--- portage.orig/bin/ebuild.sh 2009-12-14 10:18:06 +0100
+++ portage/bin/ebuild.sh 2009-12-14 14:45:55 +0100
@@ -1791,7 +1791,15 @@
fi
- EPYTHON= ${PORTAGE_BIN_PATH}/filter-bash-environment.py
${filtered_vars}
+ (
+ # at least on _some_ platforms, RPATH may contain .. now if
merging
+ # python, and PWD at call-time of this filter is ${S}, it can
be, that
+ # there is a ./libpython-x.x.so, which gets loaded. Even if the
to-be-
+ # installed is binary identical to the already-installed one:
this leads
+ # to Fatal Python error: Interpreter not initialized (version
mismatch?)
+ cd ${T}
+ EPYTHON= ${PORTAGE_BIN_PATH}/filter-bash-environment.py
${filtered_vars}
+ )
}
# @FUNCTION: preprocess_ebuild_env
@@ -2270,7 +2284,7 @@
# Save the env only for relevant phases.
if ! hasq $EBUILD_SH_ARGS clean help info nofetch ; then
umask 002
- save_ebuild_env | filter_readonly_variables
$T/environment
+ save_ebuild_env | filter_readonly_variables
$T/environment || exit $?
chown
${PORTAGE_USER:-portage}:${PORTAGE_GROUP:-portage} $T/environment /dev/null
chmod g+w $T/environment /dev/null
fi
[gentoo-portage-dev] ESTALE missing on interix
Hi! i'm here to report ESTALE beeing missing on interix ;) seems like portage is checking on it lately, so i required the attached patch to get portage working on interix again (prefix). any chance to get sth. alike in the svn tree? maybe a more generic thing? but i guess that would not be necessary Cheers, Markus diff -ru portage.orig/pym/portage/__init__.py portage/pym/portage/__init__.py --- portage.orig/pym/portage/__init__.py 2009-04-23 13:49:09 +0200 +++ portage/pym/portage/__init__.py 2009-04-23 13:50:18 +0200 @@ -15,6 +15,10 @@ import codecs import copy import errno + try: + x = errno.ESTALE + except AttributeError: + errno.ESTALE = -1 import logging import os import re
Re: [gentoo-portage-dev] ESTALE missing on interix
On Thu, 2009-04-23 at 13:55 +0200, Markus Duft wrote: Hi! i'm here to report ESTALE beeing missing on interix ;) seems like portage is checking on it lately, so i required the attached patch to get portage working on interix again (prefix). djanderson pointed out that I could have made the patch better - as I'm no python programmer, I didn't know better, so forgive me :) attached is the better one i hope. Cheers, Markus any chance to get sth. alike in the svn tree? maybe a more generic thing? but i guess that would not be necessary Cheers, Markus diff -ru portage.orig/pym/portage/__init__.py portage/pym/portage/__init__.py --- portage.orig/pym/portage/__init__.py 2009-04-23 13:49:09 +0200 +++ portage/pym/portage/__init__.py 2009-04-23 14:07:44 +0200 @@ -15,6 +15,8 @@ import codecs import copy import errno + if not hasattr(errno, 'ESTALE'): + errno.ESTALE = -1 import logging import os import re
Re: [gentoo-portage-dev] --nodeps faulty behaviour?
On Mon, 2009-04-20 at 11:05 -0700, Zac Medico wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus Duft wrote: cool thanks :) so this patch makes portage merge in the order given on the command line? this means it's the users fault if packages are in the wrong order? Right. shouldn't portage do the same thing as with --nodeps, except that it doesn't add new packages to the merge list? don't get me wrong - i'm quite happy with beeing responsible for the order, i just imageined passing (to stay with the same example) --nodeps texinfo help2man which should reorder to help2man beeing before texinfo, i would guess... thoughts? Well, what you are describing is something different from what - --nodeps is supposed to mean. The intention for --nodeps is to not account for any dependencies whatsoever. We can add a new option if you need some different behavior. hm, ok. nah i don't need it, just wanted to know ;) Cheers, Markus - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAknsuVgACgkQ/ejvha5XGaO9HQCg3zIhUqMrL2pffqft/kOQdrLu z8gAoJ+ZGkWRoQ19mRnc4WTlZ0hbMNmf =STIm -END PGP SIGNATURE-
Re: [gentoo-portage-dev] --nodeps faulty behaviour?
On Mon, 2009-04-20 at 08:35 +0200, Markus Duft wrote: Hi! I have a quick question: is --nodeps supposed to still merge packages in the right order? my specific problem is, that when i do this: emerge -pv --noreplace --oneshot --nodeps \ sys-devel/gcc-config \ sys-devel/gcc \ libperl perl help2man texinfo \ =autoconf-2.1* =autoconf-2.6* autoconf-wrapper \ =automake-1.4* =automake-1.5* =automake-1.6* \ =automake-1.7* =automake-1.8* automake-wrapper \ wget i get this: These are the packages that would be merged, in order: [ebuild N] sys-apps/texinfo-4.12 USE=-nls -static 0 kB [ebuild N] sys-devel/autoconf-2.13 0 kB [ebuild N] sys-devel/autoconf-2.63-r1 USE=(-emacs) 0 kB [ebuild N] sys-devel/automake-1.4_p6 0 kB [ebuild N] sys-devel/automake-1.5 0 kB [ebuild N] sys-devel/automake-1.6.3 0 kB [ebuild N] sys-devel/automake-1.7.9-r1 0 kB [ebuild N] sys-devel/automake-1.8.5-r3 0 kB [ebuild N] net-misc/wget-1.11.4 USE=-debug (-ipv6) -nls -socks5 -ssl -static 0 kB [ebuild N] sys-devel/gcc-config-1.4.1-r00.1 0 kB [ebuild N] sys-devel/libperl-5.8.8-r2 USE=-berkdb -debug -gdbm -ithreads 0 kB [ebuild N] dev-lang/perl-5.8.8-r5 USE=-berkdb -build -debug -doc -gdbm -ithreads -perlsuid 0 kB [ebuild N] sys-apps/help2man-1.36.4 USE=-nls 0 kB [ebuild N] sys-devel/autoconf-wrapper-6-r00.1 0 kB [ebuild N] sys-devel/automake-wrapper-3-r1 0 kB but texinfo DEPENDs on help2man - thus it fails to build. as a workaroun i split the merges into several ones which preserve dependency order, but i feel that portage should do it.. what do you think? oh, damn, sorry; this is not the right portage, was in the wrong shell :) this is the right one: Portage 2.2.00.13286-prefix (!/opt/gentoo/usr/portage/profiles/prefix/windows/interix/5.2/x86, gcc-4.2.4, unavailable, 5.2 x86) = System uname: Interix-5.2-x86-32bit Timestamp of tree: Thu, 16 Apr 2009 22:02:48 + app-shells/bash: 3.2_p48-r1 dev-lang/python: 2.5.4-r2, 2.6.1-r1 sys-devel/autoconf: 2.63-r1 sys-devel/automake: 1.9.6-r2, 1.10.2-r00.1 sys-devel/binutils: 2.18-r4 sys-devel/gcc-config: 1.4.1-r00.1 sys-devel/libtool: 2.2.6a ACCEPT_KEYWORDS=~x86-interix ... Administrator opt $ emerge --info Portage 2.2.00.13346-prefix (prefix/windows/interix/5.2/x86, gcc-4.2.4, unavailable, 5.2 x86) = System uname: Interix-5.2-x86-32bit Timestamp of tree: Thu, 16 Apr 2009 07:36:49 + app-shells/bash: 3.2_p48-r1 dev-lang/python: 2.5.4-r2, 2.6.1-r1 sys-devel/autoconf: 2.63-r1 sys-devel/automake: 1.9.6-r2, 1.10.2-r00.1 sys-devel/binutils: 2.18-r4 sys-devel/gcc-config: 1.4.1-r00.1 sys-devel/libtool: 2.2.6a ACCEPT_KEYWORDS=~x86-interix Cheers, Markus
Re: [gentoo-portage-dev] --nodeps faulty behaviour?
On Mon, 2009-04-20 at 02:14 -0700, Zac Medico wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus Duft wrote: Hi! I have a quick question: is --nodeps supposed to still merge packages in the right order? Yes. The attached patch should fix it. Thanks for reporting. cool thanks :) so this patch makes portage merge in the order given on the command line? this means it's the users fault if packages are in the wrong order? shouldn't portage do the same thing as with --nodeps, except that it doesn't add new packages to the merge list? don't get me wrong - i'm quite happy with beeing responsible for the order, i just imageined passing (to stay with the same example) --nodeps texinfo help2man which should reorder to help2man beeing before texinfo, i would guess... thoughts? Cheers, Markus - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAknsPNIACgkQ/ejvha5XGaN6EQCfUWVR2U+gCrqv60uMzAssbzm0 VxUAnjsah7byJwKRO/FVoZWwr0i4kBmE =X0E7 -END PGP SIGNATURE- plain text document attachment (nodeps_order.patch) Index: pym/_emerge/__init__.py === --- pym/_emerge/__init__.py (revision 13376) +++ pym/_emerge/__init__.py (revision 13377) @@ -7039,6 +7039,13 @@ writemsg(\n, noiselevel=-1) scheduler_graph = self.digraph.copy() + + if '--nodeps' in self.myopts: + # Preserve the package order given on the command line. + return ([node for node in scheduler_graph \ + if isinstance(node, Package) \ + and node.operation == 'merge'], scheduler_graph) + mygraph=self.digraph.copy() # Prune nomerge root nodes if nothing depends on them, since # otherwise they slow down merge order calculation. Don't remove
Re: [gentoo-portage-dev] prefix portage chaining
On Wed, 2009-03-25 at 11:44 -0700, Ned Ludd wrote:
[snip]
While much of what you are talking about here mainly applies to prefix,
it looks to me from glancing over the code that you might of solved a
long standing problem in the embedded world with cross compiling via
portage. 222895 If that is the case, then I owe you a beer. one about
the size of a keg.
lol, thx for the beer ;)
hmm... looking over that patch again, the only EPREFIX dependent thing
is, that i'm removing EPREFIX from the vartree class again :) so this
should pretty much plain apply to main too, and simply work. you may
want to rename READONLY_EPREFIX to READONLY_ROOT, but thats it :)
the other stuff besides portage modification (baselayout patchery, etc.
is prefix specific again, so all you'd need is the portage changes.
if you will try it, please let me know if it worked :) with the attached
patch sed -i -e 's,READONLY_EPREFIX,READONLY_ROOT,g', and applying to
an installed /usr/lib/portage should enable you to do it.
(backup /usr/lib/portage - i trust my work, but... we never know for
sure :))
then add to make.conf: READONLY_ROOT=/my/other/root:DEPEND
i hope this is what you where looking for...! and i hope it doesn't
somehow clash with the existing cross compile logic in portage regarding
where to merge to...
Cheers, Markus
diff -ru portage.orig/bin/ebuild.sh portage/bin/ebuild.sh
--- portage.orig/bin/ebuild.sh 2009-03-24 16:44:15.0 +0100
+++ portage/bin/ebuild.sh 2009-03-25 07:32:07.0 +0100
@@ -69,7 +69,38 @@
# Unset some variables that break things.
unset GZIP BZIP BZIP2 CDPATH GREP_OPTIONS GREP_COLOR GLOBIGNORE
-export PATH=${DEFAULT_PATH}:$PORTAGE_BIN_PATH/ebuild-helpers:${ROOTPATH}
+if [[ -n ${PORTAGE_READONLY_EROOTS} ]]; then
+ new_PATH=$PORTAGE_BIN_PATH/ebuild-helpers:${ROOTPATH}
+
+ save_IFS=$IFS
+ IFS=':'
+
+ for eroot in ${PORTAGE_READONLY_EROOTS}:${EPREFIX}; do
+ IFS=$save_IFS
+ [[ -f ${eroot}/usr/share/portage/config/make.globals ]] || continue
+ defpath=$(. ${eroot}/etc/make.globals echo $DEFAULT_PATH)
+ okpath=
+ save_IFS2=$IFS
+ IFS=':'
+ for p in $defpath; do
+ IFS=$save_IFS2
+ [[ :${new_PATH}: == *:$p:* ]] continue
+ if [[ -z ${okpath} ]]; then
+okpath=${p}
+ else
+okpath=${okpath}:${p}
+ fi
+ done
+ IFS=$save_IFS2
+
+ new_PATH=${okpath}:${new_PATH}
+ done
+ IFS=$save_IFS
+
+ export PATH=$new_PATH
+else
+ export PATH=${DEFAULT_PATH}:$PORTAGE_BIN_PATH/ebuild-helpers:${ROOTPATH}
+fi
[ ! -z $PREROOTPATH ] export PATH=${PREROOTPATH%%:}:$PATH
source ${PORTAGE_BIN_PATH}/isolated-functions.sh /dev/null
diff -ru portage.orig/pym/_emerge/__init__.py portage/pym/_emerge/__init__.py
--- portage.orig/pym/_emerge/__init__.py 2009-03-24 16:43:02.0 +0100
+++ portage/pym/_emerge/__init__.py 2009-03-24 16:42:51.0 +0100
@@ -5269,17 +5269,18 @@
edepend[DEPEND] =
deps = (
- (/, edepend[DEPEND],
+ (/, DEPEND,
self._priority(buildtime=(not bdeps_optional),
optional=bdeps_optional)),
- (myroot, edepend[RDEPEND], self._priority(runtime=True)),
- (myroot, edepend[PDEPEND], self._priority(runtime_post=True))
+ (myroot, RDEPEND, self._priority(runtime=True)),
+ (myroot, PDEPEND, self._priority(runtime_post=True))
)
debug = --debug in self.myopts
strict = mytype != installed
try:
- for dep_root, dep_string, dep_priority in deps:
+ for dep_root, dep_type, dep_priority in deps:
+dep_string = edepend[dep_type]
if not dep_string:
continue
if debug:
@@ -5289,9 +5290,11 @@
print Priority:, dep_priority
vardb = self.roots[dep_root].trees[vartree].dbapi
try:
+ # MDUFT: selected_atoms will not contain anything
+ # that can be resolved from a readonly root!
selected_atoms = self._select_atoms(dep_root,
dep_string, myuse=myuse, parent=pkg, strict=strict,
- priority=dep_priority)
+ priority=dep_priority, dep_type=dep_type)
except portage.exception.InvalidDependString, e:
show_invalid_depstring_notice(jbigkey, dep_string, str(e))
return 0
@@ -5916,12 +5919,18 @@
return self._select_atoms_highest_available(*pargs, **kwargs)
def _select_atoms_highest_available(self, root, depstring,
- myuse=None, parent=None, strict=True, trees=None, priority=None):
+ myuse=None, parent=None, strict=True, trees=None, priority=None, dep_type=None):
This will raise InvalidDependString if necessary. If trees is
None then self._filtered_trees is used.
pkgsettings = self.pkgsettings[root]
if trees is None:
trees = self._filtered_trees
+
+ # this one is needed to guarantee good readonly root
+ # resolution display in the merge list. required since
+ # parent (below) can be None
+ trees[root][disp_parent] = parent
+
if not getattr(priority, buildtime, False):
# The parent should only be passed to dep_check() for buildtime
# dependencies since that's the only case when it's appropriate
@@ -5938,7 +5947,7 @@
Re: [gentoo-portage-dev] prefix portage chaining
On Wed, 2009-03-25 at 12:00 +0100, Fabian Groffen wrote: On 20-03-2009 11:35:09 +0100, Markus Duft wrote: i'll try and explain what i want in the first place: i'm porting things to native windows. since windows isn't too cooperative, i'm unable to merge most things (and with other things, i simply don't want to), and thus i need to take those things from somewhere else (more or less the complete @system). I _am_ able to build all those things for interix (which is the host system in the windows case). So what i want is a setup of two prefix instances with a certain relation to each other: the native windows prefix should be able to recognize installed packages from the other instance, and resolve dependencies by eventually using the other .../var/db/... Since Windows and Interix seem to be two different things to me, can you explain why in this case Portage can resolve the dependencies from the Interix system to use for the Windows system? What dependencies are we talking about? Build tools? Libraries? Runtime dependencies? i'm using it to resolve DEPEND atoms only. of course my notion of valid DEPENDs and RDEPENDs is influenced by this, and i'm alergic against RDEPEND=$DEPEND and such :) since it doesn't work in this setup. however right now most things i need don't make too much problems. This could be (and is) quite usefull for all other platforms too. For exmaple i could use prefix chaining on a linux box. I could create a prefix containing a base system, and then for testing of i-don't-know-whatever, i could create another small prefix inheriting all installed packages from the other one. this way new prefixes can stay very slim, but still the parent prefix is not altered on merges. That potentially is useful, in the case where you want to upgrade a critical system package and test it out or something. Can't think of an example other than Portage itself for the moment, though. (And that one can be hairy, for instance if the vdb format changes NEEDED - NEEDED.ELF.2) ++ :) one issue not handled by the current patch is, that prefixes can have different CHOST/ARCH/... (which is the case with x86-interix and x86-winnt for example). Then how does it work for you? as i said, i'm using DEPENDs only from the other prefix with the different CHOST/ARCH. this works, since on interix i can execute windows binaries, and vice versa (limited). the patch i proposed here and on gentoo-alt@ (btw. i have a fixed version lying around since a few minutes ...) allows the user to set which atoms should be resolve-able from the chain. for exmaple for windows i'm doing this in /my/winnt/prefix/etc/make.conf: READONLY_EROOT=/my/interix/prefix:DEPEND on linux, if both prefixes are x86-linux for example i could to in /my/prefix/two/etc/make.conf: READONLY_EROOT=/my/prefix/one:DEPEND,RDEPEND (btw. this forces PDEPENDs to merge in /my/prefix/two. i guess most of the time this makes sense, since with a PDEPEND from a lib, i want the PDEPEND package to link against this lib... you know what i mean? of course PDEPEND can still be added to the above list...) (btw2. the name READONLY_EROOT is discussed on gentoo-alt@ already, so i won't comment on it beeing cool/uncool here... ;) ) Cheers, Markus
Re: [gentoo-portage-dev] prefix portage chaining
On Mon, 2009-03-23 at 08:27 +0100, Markus Duft wrote:
On Fri, 2009-03-20 at 12:11 +0100, Markus Duft wrote:
On Fri, 2009-03-20 at 11:35 +0100, Markus Duft wrote:
Hey guys :)
Just wanted to stop by and get some opinions on a patch i wrote for the
prefix branch.
[snip]
Hey there. Seemingly nobody has any comments on this..? :) here's a
working version of the patch. i realized that the last one worked only
by accident :) maybe now, some comments (or questions)?
i'm eager to find out how many times i can forget to attach the patch :)
sorry for the noise
Cheers, Markus
Thanks, Cheers, Markus
[snip]
Waiting for comments, suggestions, etc.
Thanks in advance,
Cheers, Markus
diff -ru portage.orig/pym/_emerge/__init__.py portage/pym/_emerge/__init__.py
--- portage.orig/pym/_emerge/__init__.py 2009-03-18 10:13:34.0 +0100
+++ portage/pym/_emerge/__init__.py 2009-03-23 08:46:59.0 +0100
@@ -49,7 +49,7 @@
import portage.xpak, commands, errno, re, socket, time
from portage.output import blue, bold, colorize, darkblue, darkgreen, darkred, green, \
nc_len, red, teal, turquoise, xtermTitle, \
- xtermTitleReset, yellow
+ xtermTitleReset, yellow, purple
from portage.output import create_color_func
good = create_color_func(GOOD)
bad = create_color_func(BAD)
@@ -69,6 +69,7 @@
from portage.util import cmp_sort_key, writemsg, writemsg_level
from portage.sets import load_default_config, SETPREFIX
from portage.sets.base import InternalPackageSet
+from portage.dbapi.vartree import vartree
from itertools import chain, izip
@@ -4692,6 +4693,7 @@
self._unsatisfied_deps_for_display = []
self._unsatisfied_blockers_for_display = None
self._circular_deps_for_display = None
+ self._injected_readonly_deps_for_display = []
self._dep_stack = []
self._unsatisfied_deps = []
self._initially_unsatisfied_deps = []
@@ -5270,18 +5272,35 @@
if removal_action and self.myopts.get(--with-bdeps, y) == n:
edepend[DEPEND] =
+ # MDUFT: create additional vartrees for every readonly root here
+ # (maybe FakeVartree's?). Then below search those trees and set
+ # mypriority.satisfied to True.
+ # the ro_vartrees instances are created below as they are needed to
+ # avoid reading vartrees of portage instances which aren't required
+ # while resolving this dependencies.
+ ro_trees = {}
+ ro_vartrees = {}
+
+ for type in (DEPEND,RDEPEND, PDEPEND):
+ ro_trees[type] = []
+
+ for ro_root, ro_dep_types in self.settings.readonly_roots.items():
+if type in ro_dep_types:
+ ro_trees[type].append(ro_root)
+
deps = (
- (/, edepend[DEPEND],
+ (/, DEPEND,
self._priority(buildtime=(not bdeps_optional),
optional=bdeps_optional)),
- (myroot, edepend[RDEPEND], self._priority(runtime=True)),
- (myroot, edepend[PDEPEND], self._priority(runtime_post=True))
+ (myroot, RDEPEND, self._priority(runtime=True)),
+ (myroot, PDEPEND, self._priority(runtime_post=True))
)
debug = --debug in self.myopts
strict = mytype != installed
try:
- for dep_root, dep_string, dep_priority in deps:
+ for dep_root, dep_type, dep_priority in deps:
+dep_string = edepend[dep_type]
if not dep_string:
continue
if debug:
@@ -5309,6 +5328,43 @@
if not atom.blocker and vardb.match(atom):
mypriority.satisfied = True
+ # MDUFT: How erver we do it - if we find atom beeing installed
+ # in a valid readonly root for the current dependency type, then
+ # _DONT_ call the below, but rather return 1 immediately.
+ ro_matched = False
+ for ro_root in ro_trees[dep_type]:
+ if not ro_vartrees.has_key(ro_root):
+# target_root=ro_root ok? or should it be the real target_root?
+_tmp_settings = portage.config(config_root=ro_root, target_root=ro_root,
+ config_incrementals=portage.const.INCREMENTALS)
+#_tmp_trees = portage.util.LazyItemsDict()
+#_tmp_trees.addLazySingleton(vartree, vartree, ro_root,
+# categories=_tmp_settings.categories, settings=_tmp_settings)
+
+#setconfig = load_default_config(_tmp_trees[vartree].settings, _tmp_trees)
+#ro_vartrees[ro_root] = FakeVartree(RootConfig(_tmp_trees[vartree].settings,
+# _tmp_trees, setconfig), acquire_lock=0)
+
+ro_vartrees[ro_root] = vartree(root=ro_root, categories=_tmp_settings.categories,
+ settings=_tmp_settings, kill_eprefix=True)
+
+ ro_matches = ro_vartrees[ro_root].dbapi.match(atom)
+
+ if ro_matches:
+if dep_type is RDEPEND:
+ # we need to assure binary compatability, so it needs to be
+ # the same CHOST! But how? for now i cannot do anything...
+ pass
+
+# injected dep for display. those get shown with the merge list.
+self._injected_readonly_deps_for_display.append({ro_root : ro_root, atom : atom,
+ matches: ro_matches, type
[gentoo-portage-dev] prefix portage chaining
Hey guys :) Just wanted to stop by and get some opinions on a patch i wrote for the prefix branch. i'll try and explain what i want in the first place: i'm porting things to native windows. since windows isn't too cooperative, i'm unable to merge most things (and with other things, i simply don't want to), and thus i need to take those things from somewhere else (more or less the complete @system). I _am_ able to build all those things for interix (which is the host system in the windows case). So what i want is a setup of two prefix instances with a certain relation to each other: the native windows prefix should be able to recognize installed packages from the other instance, and resolve dependencies by eventually using the other .../var/db/... This could be (and is) quite usefull for all other platforms too. For exmaple i could use prefix chaining on a linux box. I could create a prefix containing a base system, and then for testing of i-don't-know-whatever, i could create another small prefix inheriting all installed packages from the other one. this way new prefixes can stay very slim, but still the parent prefix is not altered on merges. one issue not handled by the current patch is, that prefixes can have different CHOST/ARCH/... (which is the case with x86-interix and x86-winnt for example). another thing is, that i plan to add some output in the merge list, telling the user, which packages have been readonly-resolved from another portage instance. right now the dependency is treated as if it didn't exist. all together, i'm pretty sure i did the one or the other forbidden thing in my patch, but that's why i'm asking the guys-who-know :) it was hard enough to read the portage source and get where i am, so i'm happy with the result ;) Waiting for comments, suggestions, etc. Thanks in advance, Cheers, Markus
Re: [gentoo-portage-dev] prefix portage chaining
On Fri, 2009-03-20 at 11:35 +0100, Markus Duft wrote:
Hey guys :)
Just wanted to stop by and get some opinions on a patch i wrote for the
prefix branch.
argh... managed to fail to attach the patch _again_ :) at least i
managed to add the output stuff i mentioned before to the patch in the
meantime. so this patch should be pretty much complete.
Thanks and Cheers, Markus
i'll try and explain what i want in the first place: i'm porting things
to native windows. since windows isn't too cooperative, i'm unable to
merge most things (and with other things, i simply don't want to), and
thus i need to take those things from somewhere else (more or less the
complete @system). I _am_ able to build all those things for interix
(which is the host system in the windows case). So what i want is a
setup of two prefix instances with a certain relation to each other: the
native windows prefix should be able to recognize installed packages
from the other instance, and resolve dependencies by eventually using
the other .../var/db/...
This could be (and is) quite usefull for all other platforms too. For
exmaple i could use prefix chaining on a linux box. I could create a
prefix containing a base system, and then for testing of
i-don't-know-whatever, i could create another small prefix inheriting
all installed packages from the other one. this way new prefixes can
stay very slim, but still the parent prefix is not altered on merges.
one issue not handled by the current patch is, that prefixes can have
different CHOST/ARCH/... (which is the case with x86-interix and
x86-winnt for example).
another thing is, that i plan to add some output in the merge list,
telling the user, which packages have been readonly-resolved from
another portage instance. right now the dependency is treated as if it
didn't exist.
all together, i'm pretty sure i did the one or the other forbidden thing
in my patch, but that's why i'm asking the guys-who-know :) it was hard
enough to read the portage source and get where i am, so i'm happy with
the result ;)
Waiting for comments, suggestions, etc.
Thanks in advance,
Cheers, Markus
diff -ru portage.orig/pym/_emerge/__init__.py portage/pym/_emerge/__init__.py
--- portage.orig/pym/_emerge/__init__.py 2009-03-18 10:13:34.0 +0100
+++ portage/pym/_emerge/__init__.py 2009-03-20 12:08:49.0 +0100
@@ -49,7 +49,7 @@
import portage.xpak, commands, errno, re, socket, time
from portage.output import blue, bold, colorize, darkblue, darkgreen, darkred, green, \
nc_len, red, teal, turquoise, xtermTitle, \
- xtermTitleReset, yellow
+ xtermTitleReset, yellow, purple
from portage.output import create_color_func
good = create_color_func(GOOD)
bad = create_color_func(BAD)
@@ -69,6 +69,7 @@
from portage.util import cmp_sort_key, writemsg, writemsg_level
from portage.sets import load_default_config, SETPREFIX
from portage.sets.base import InternalPackageSet
+from portage.dbapi.vartree import vartree
from itertools import chain, izip
@@ -4692,6 +4693,7 @@
self._unsatisfied_deps_for_display = []
self._unsatisfied_blockers_for_display = None
self._circular_deps_for_display = None
+ self._injected_readonly_deps_for_display = []
self._dep_stack = []
self._unsatisfied_deps = []
self._initially_unsatisfied_deps = []
@@ -5270,18 +5272,35 @@
if removal_action and self.myopts.get(--with-bdeps, y) == n:
edepend[DEPEND] =
+ # MDUFT: create additional vartrees for every readonly root here
+ # (maybe FakeVartree's?). Then below search those trees and set
+ # mypriority.satisfied to True.
+ # the ro_vartrees instances are created below as they are needed to
+ # avoid reading vartrees of portage instances which aren't required
+ # while resolving this dependencies.
+ ro_trees = {}
+ ro_vartrees = {}
+
+ for type in (DEPEND,RDEPEND, PDEPEND):
+ ro_trees[type] = []
+
+ for ro_root, ro_dep_types in self.settings.readonly_roots.items():
+if type in ro_dep_types:
+ ro_trees[type].append(ro_root)
+
deps = (
- (/, edepend[DEPEND],
+ (/, DEPEND,
self._priority(buildtime=(not bdeps_optional),
optional=bdeps_optional)),
- (myroot, edepend[RDEPEND], self._priority(runtime=True)),
- (myroot, edepend[PDEPEND], self._priority(runtime_post=True))
+ (myroot, RDEPEND, self._priority(runtime=True)),
+ (myroot, PDEPEND, self._priority(runtime_post=True))
)
debug = --debug in self.myopts
strict = mytype != installed
try:
- for dep_root, dep_string, dep_priority in deps:
+ for dep_root, dep_type, dep_priority in deps:
+dep_string = edepend[dep_type]
if not dep_string:
continue
if debug:
@@ -5309,6 +5328,32 @@
if not atom.blocker and vardb.match(atom):
mypriority.satisfied = True
+ # MDUFT: How erver we do it - if we find atom beeing installed
+ # in a valid readonly root for the current dependency type, then
+ # _DONT_ call
