Re: [gentoo-dev] splitting out arm keywords
On Wednesday 09 July 2014 03:48:40 Matthew Thode wrote: arm has a historical problem with stabilization, while keywording doesn't require access to all arm sub-arches the problem with the stabilization slowness causes running a full ~arm to become hard. By that I mean that if someone keywords something for arm because it works on armv7 and I run ~arm because stabilization takes forever then my system may break because of both non-stabilized packages and because I could be running armv6. So how common is it for a package to work correctly on armv7 but break on armv6? As far as I can see, splitting the keywords is a good idea if and only if this is common. In any case I propose splitting out arm into armv4, armv5, armv6 and armv7. armv8 seems to be here already as arm64. Do you foresee ~armv4 and ~armv5 keywords actually showing up in practice? I think this would be beneficial because of not all developers that want to help with arm have or what all the sub-arches necessary. It also allows us to move faster on stabilization because most of us have access to armv7 a bit easier. This would take some pressure off of the people doing stabilization for older sub-arches, but not much. Some issues that need solving are as follows. [hard|soft]float differences. what stabilization means would need to be clarified a bit here. The same issue as above applies. Do packages commonly break or unbreak depending on hardfloat versus softfloat? -- Ruud
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tuesday 14 January 2014 22:37:19 William Hubbs wrote: I think we need a global policy that either helps keep the stable tree up to date or reverts an architecture to ~ over time if the arch team can't keep up. As a compromise solution for minor archs, it would be nice if there were a portage feature allowing me to ACCEPT_KEYWORDS those packages that are keyworded both ~arch, and stable on some major arch. For example, on m68k, it would select packages that are keyworded ~m68k amd64, or ~m68k x86, etc. This would allow me to run m68k kinda stable. [Speculation as to applying a similar system more broadly witheld.] -- Ruud
[gentoo-dev] New globally masked prefix USE flag
Ohai, As part of the RAP project[1], a version of Gentoo Prefix that uses its own libc rather than relying on the host version, prefix needs some new profiles serving this variant. While this is entirely inconsequential for most packages, there are a handful of ebuilds that need to distinguish between the two prefix variants. The chief difference between the two variants from the point of view of ebuilds is that in classic prefix, the host /usr/include is a valid include path (as it contains libc headers), whereas in RAP prefix it is not, and analogously so for library paths; this needs special handling for packages with build scripts that do their own exiting custom library searching, such as python, which needs to do certain prefix-specific hacks only for classic prefix and not for RAP. To this end, I'm introducing a globally masked USE flag, prefix-guest, which is masked in the base profile and unmasked and forced in some prefix profiles; this flag indicates that /usr/include, /lib, and /usr/lib are valid paths despite being on a prefix system. This flag will be on in classic prefix, and off in prefix RAP. I will proceed in a week, assuming no complaints arise. -- Ruud [1] http://blogs.gentoo.org/news/2013/11/01/gentoo-monthly-newsletter-31-october-2013/#RAP
Re: [IDEA] Enumerate solutions for blockers, to avoid tedious manual work. (was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)
On Sunday 03 November 2013 13:10:57 Tom Wijsman wrote: Let's say I have the blocker: dev-python/python-exec-1 is blocking dev-lang/python-exec-0.3.1 We could have it additionally say something like: To resolve this blocker, you can run one of the following commands: emerge -1 '=dev-python/python-exec-1' If portage can do that, what exactly is keeping it from resolving the situation fully automatically? If it reliably knows what to emerge to get unstuck, it sounds like it would only be a trivial step to actually add this information to the dependency resolver. -- Ruud
[gentoo-portage-dev] [PATCH 2/3] Based GLOBAL_CONFIG_PATH and DEPCACHE_PATH on portage prefix
The GLOBAL_CONFIG_PATH constants and DEPCACHE_PATH constants should be relative to the installation prefix of portage itself, not the installation prefix of packages it is installing. --- pym/_emerge/actions.py |6 --- pym/portage/_sets/__init__.py |3 -- pym/portage/const.py | 34 ++-- .../package/ebuild/_config/LocationsManager.py | 22 - pym/portage/package/ebuild/config.py | 15 - pym/portage/package/ebuild/fetch.py|4 -- pym/portage/tests/resolver/ResolverPlayground.py |3 +- 7 files changed, 18 insertions(+), 69 deletions(-) diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py index 767a614..c76aefc 100644 --- a/pym/_emerge/actions.py +++ b/pym/_emerge/actions.py @@ -2019,9 +2019,6 @@ def action_sync(settings, trees, mtimedb, myopts, myaction): myportdir = None out = portage.output.EOutput() global_config_path = GLOBAL_CONFIG_PATH - if settings['EPREFIX']: - global_config_path = os.path.join(settings['EPREFIX'], - GLOBAL_CONFIG_PATH.lstrip(os.sep)) if not myportdir: sys.stderr.write(!!! PORTDIR is undefined. + \ Is %s/make.globals missing?\n % global_config_path) @@ -3332,9 +3329,6 @@ def missing_sets_warning(root_config, missing_sets): if root_config.sets: msg.append(sets defined: %s % , .join(root_config.sets)) global_config_path = portage.const.GLOBAL_CONFIG_PATH - if root_config.settings['EPREFIX']: - global_config_path = os.path.join(root_config.settings['EPREFIX'], - portage.const.GLOBAL_CONFIG_PATH.lstrip(os.sep)) msg.append(This usually means that '%s' % \ (os.path.join(global_config_path, sets/portage.conf),)) msg.append(is missing or corrupt.) diff --git a/pym/portage/_sets/__init__.py b/pym/portage/_sets/__init__.py index c196a70..8123af7 100644 --- a/pym/portage/_sets/__init__.py +++ b/pym/portage/_sets/__init__.py @@ -295,9 +295,6 @@ def load_default_config(settings, trees): return SetConfig(None, settings, trees) global_config_path = GLOBAL_CONFIG_PATH - if settings['EPREFIX']: - global_config_path = os.path.join(settings['EPREFIX'], - GLOBAL_CONFIG_PATH.lstrip(os.sep)) def _getfiles(): for path, dirs, files in os.walk(os.path.join(global_config_path, sets)): for f in files: diff --git a/pym/portage/const.py b/pym/portage/const.py index 5e960d9..d22d144 100644 --- a/pym/portage/const.py +++ b/pym/portage/const.py @@ -52,10 +52,23 @@ WORLD_SETS_FILE = PRIVATE_PATH + /world_sets CONFIG_MEMORY_FILE = PRIVATE_PATH + /config NEWS_LIB_PATH= var/lib/gentoo -# these variables get EPREFIX prepended automagically when they are -# translated into their lowercase variants -DEPCACHE_PATH= /var/cache/edb/dep -GLOBAL_CONFIG_PATH = /usr/share/portage/config +# The EPREFIX for the current install is hardcoded here, but access to this +# constant should be minimal, in favor of access via the EPREFIX setting of +# a config instance (since it's possible to contruct a config instance with +# a different EPREFIX). +EPREFIX= + +# pick up EPREFIX from the environment if set +if PORTAGE_OVERRIDE_EPREFIX in os.environ: + EPREFIX = os.environ[PORTAGE_OVERRIDE_EPREFIX] + if EPREFIX: + EPREFIX = os.path.normpath(EPREFIX) + +# these variables are based on the prefix of the portage installation, not +# the prefix of the installed packages, and as such use the builtin EPREFIX +# rather than the EPREFIX setting in a config instance. +DEPCACHE_PATH= EPREFIX + /var/cache/edb/dep +GLOBAL_CONFIG_PATH = EPREFIX + /usr/share/portage/config # these variables are not used with target_root or config_root # NOTE: Use realpath(__file__) so that python module symlinks in site-packages @@ -152,19 +165,6 @@ MANIFEST2_REQUIRED_HASH = SHA256 MANIFEST2_IDENTIFIERS= (AUX, MISC, DIST, EBUILD) -# The EPREFIX for the current install is hardcoded here, but access to this -# constant should be minimal, in favor of access via the EPREFIX setting of -# a config instance (since it's possible to contruct a config instance with -# a different EPREFIX). Therefore, the EPREFIX constant should *NOT* be used -# in the definition of any other constants within this file. -EPREFIX= - -# pick up EPREFIX from the environment if set -if PORTAGE_OVERRIDE_EPREFIX in os.environ: - EPREFIX = os.environ[PORTAGE_OVERRIDE_EPREFIX] - if EPREFIX: - EPREFIX = os.path.normpath(EPREFIX) - VCS_DIRS = (CVS, RCS, SCCS, .bzr, .git, .hg, .svn) #
[gentoo-portage-dev] [PATCH 3/3] Pick up EPREFIX environment variable
This adds support for picking up the EPREFIX config setting from the EPREFIX
environment variable. An emerge --prefix option is added to specify it,
analogous to --root and --config-root options.
---
pym/_emerge/actions.py |3 ++-
pym/_emerge/main.py |7 +++
pym/portage/_legacy_globals.py |3 ++-
pym/portage/package/ebuild/config.py |6 --
4 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py
index c76aefc..89766f1 100644
--- a/pym/_emerge/actions.py
+++ b/pym/_emerge/actions.py
@@ -3148,7 +3148,8 @@ def load_emerge_config(emerge_config=None, **kargs):
emerge_config = _emerge_config(**kargs)
kwargs = {}
- for k, envvar in ((config_root, PORTAGE_CONFIGROOT),
(target_root, ROOT)):
+ for k, envvar in ((config_root, PORTAGE_CONFIGROOT),
(target_root, ROOT),
+ (eprefix, EPREFIX)):
v = os.environ.get(envvar, None)
if v and v.strip():
kwargs[k] = v
diff --git a/pym/_emerge/main.py b/pym/_emerge/main.py
index 689d136..c67f70b 100644
--- a/pym/_emerge/main.py
+++ b/pym/_emerge/main.py
@@ -541,6 +541,11 @@ def parse_opts(tmpcmdline, silent=False):
choices : true_y_or_n
},
+ --prefix: {
+ help : specify the installation prefix,
+ action : store
+ },
+
--quiet: {
shortopt : -q,
help : reduced or condensed output,
@@ -1024,6 +1029,8 @@ def emerge_main(args=None):
os.environ[PORTAGE_CONFIGROOT] = myopts[--config-root]
if --root in myopts:
os.environ[ROOT] = myopts[--root]
+ if --prefix in myopts:
+ os.environ[EPREFIX] = myopts[--prefix]
if --accept-properties in myopts:
os.environ[ACCEPT_PROPERTIES] = myopts[--accept-properties]
if --accept-restrict in myopts:
diff --git a/pym/portage/_legacy_globals.py b/pym/portage/_legacy_globals.py
index abffa0e..bb9691a 100644
--- a/pym/portage/_legacy_globals.py
+++ b/pym/portage/_legacy_globals.py
@@ -27,7 +27,8 @@ def _get_legacy_global(name):
os.umask(0o22)
kwargs = {}
- for k, envvar in ((config_root, PORTAGE_CONFIGROOT),
(target_root, ROOT)):
+ for k, envvar in ((config_root, PORTAGE_CONFIGROOT),
+ (target_root, ROOT), (eprefix, EPREFIX)):
kwargs[k] = os.environ.get(envvar)
portage._initializing_globals = True
diff --git a/pym/portage/package/ebuild/config.py
b/pym/portage/package/ebuild/config.py
index ea3839f..199a0f5 100644
--- a/pym/portage/package/ebuild/config.py
+++ b/pym/portage/package/ebuild/config.py
@@ -594,14 +594,8 @@ class config(object):
self.backup_changes(PORTAGE_CONFIGROOT)
self[ROOT] = target_root
self.backup_changes(ROOT)
-
- # The PORTAGE_OVERRIDE_EPREFIX variable propagates the
EPREFIX
- # of this config instance to any portage commands or API
- # consumers running in subprocesses.
self[EPREFIX] = eprefix
self.backup_changes(EPREFIX)
- self[PORTAGE_OVERRIDE_EPREFIX] = eprefix
- self.backup_changes(PORTAGE_OVERRIDE_EPREFIX)
self[EROOT] = eroot
self.backup_changes(EROOT)
--
1.7.2.5
