[gentoo-portage-dev] [RFC] Auto-select slots based on system configuration
It seems to me like there are a number of things that should be able to hint that you want some particular slots of particular packages, such that --depclean doesn't remove them and emerge world updates them. For example, it shouldn't remove the version of gentoo-sources that your /usr/src/linux symlink points to. It shouldn't remove the version of emacs you've got eselected. It shouldn't remove a version of tomcat that you've got in your default runlevel. It shouldn't remove the Java VM that java-config is set to. For each of these, I think it should handle this information as if the particular slot were in your world file, so long as the system is configured that way (that is, it shouldn't actually record it in the world file that way, but it should act like it saw it there). Would this be a generally good concept, if I came up with a suitable implementation? (Now that the code is set up to carry out the implications of such a setting) -Daniel *This .sig left intentionally blank* -- gentoo-portage-dev@lists.gentoo.org mailing list
[gentoo-portage-dev] [RFC] Guessing a package by short name
I think emerge should be able to do better with guessing what I mean by sudo. How about, if: 1) ask or pretend is on, and 2) exactly one package with a given short name is in world or is installed it will print a message explaining the ambiguity, but will proceed with the package from world. (1 means that the user has a chance to confirm the choice before anything actually happens; 2 means portage has some guess as to which is desired.) -Daniel *This .sig left intentionally blank* -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] keyword anti-match (foo/-foo) overrides other matches
On Tue, 28 Nov 2006, Zac Medico wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Barkalow wrote: If the configuration has keywords foo bar, and a package has -foo bar, mask the package (masked by -bar keyword). This is the sensible behavior if we ever make use of listing multiple keywords in the configuration, which is currently implemented but not used for anything. Personally, I'd prefer not to support -foo or -* in the KEYWORDS of an ebuild. For one thing, seems like it's trying to accomplish something similar to what package.mask is intended for. It's documented in the Ebuild HOWTO (at least, -foo). And the current state is sort of broken: if you manage to get -foo in your ACCEPT_KEYWORDS, you can build a known-broken package, but you can never build a package that doesn't have -foo/~foo/foo. So you can only build a package if you know it doesn't work. I'd say, make it impossible to set -foo (or -*) in ACCEPT_KEYWORDS. People who want to build -foo packages can use * (or ~*) in their package.keywords, which actually gives you the latest version that's stable somewhere (or testing somewhere). With my patch, you'd additionally need -foo in package.keywords to build a -foo package, but then it means don't worry about my foo keyword, which is appropriate and really is the usual incremental stack thing. Incidently, I think with current trunk a package.keywords value of -x86 means use an ebuild if and only if it is broken on x86, meaning that if a newer version actually works, users using the broken version won't upgrade. I bet that's not really what people want. Another problem is that is uses -foo and -* in completely different ways than they are used elsewhere in portage (for negation of values in an incremental stack). I think KEYWORDS (as opposed to ACCEPT_KEYWORDS) being thought of as an incremental stack is sort of broken. (Not that it isn't done, but I think that KEYWORDS in eclasses is just evil and generally wrong; check out enlightenment.eclass and x11-wm/e/e-.ebuild for weird and wrong.) But maybe !foo would be more appropriate anyway for don't match if foo. It might confuse people if what you do to unmask a !foo package is -foo * (meaning hide my foo keyword, match anything that works), not !foo. Although I think the real way of unmasking these things should be to put a modified version in your overlay. -Daniel *This .sig left intentionally blank* -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] [PATCH] keyword anti-match (foo/-foo) overrides other matches
If the configuration has keywords foo bar, and a package has -foo bar, mask the package (masked by -bar keyword). This is the sensible behavior if we ever make use of listing multiple keywords in the configuration, which is currently implemented but not used for anything. Signed-off-by: Daniel Barkalow [EMAIL PROTECTED] --- main/trunk/pym/portage.py | 11 +++ 1 files changed, 7 insertions(+), 4 deletions(-) diff -u a/main/trunk/pym/portage.py b/main/trunk/pym/portage.py --- a/main/trunk/pym/portage.py +++ b/main/trunk/pym/portage.py @@ -4097,9 +4097,11 @@ def getmaskingstatus(mycpv, settings=Non kmask = missing - for keyword in pgroups: - if keyword in mygroups: + for keyword in mygroups: + if keyword in pgroups: kmask=None + elif keyword[0]==- and keyword[1:] in pgroups: + kmask=keyword if kmask: fallback = None @@ -5614,14 +5616,15 @@ class portdbapi(dbapi): writemsg(--- WARNING: Package '%s' uses '*' keyword.\n % mycpv, noiselevel=-1) match=1 - break elif gp in pgroups: match=1 - break elif gp[0] == ~: hastesting = True elif gp[0] != -: hasstable = True + elif gp[1:] in pgroups: + match=0 + break if not match and ((hastesting and ~* in pgroups) or (hasstable and * in pgroups)): match=1 if match and eapi_is_supported(eapi): -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] [RFC] Mask packages that don't cross-compile
There are packages (such as perl) which work fine on both x86 and arm, but don't build on x86 cross-compiling for arm. Furthermore, pam-0.78 can be cross-compiled (with a patch available in bug comments), but pam-0.99 will require more work to get to cross-compile. It would be useful to be able to have 0.99 use a keyword (or something) such that it is excluded from cross-compiles and these builds get 0.78 instead. I've got a working patch that extends the KEYWORDS semantics slightly, such that, if KEYWORDS includes -foo, and ACCEPT_KEYWORDS includes foo but not -foo, the package is masked, even if KEYWORDS also includes bar and ACCEPT_KEYWORDS also includes bar. Then you can have the ACCEPT_KEYWORDS value $ARCH cross and packages with KEYWORDS including -cross will be masked, unless you have -cross in packages.keywords. This probably horribly mangles the concept of KEYWORDS, but I can't really tell from reading the documentation that it doesn't work this way. (Of course, I know it doesn't from trying things and reading the source, but...) It doesn't specify whether foo or -bar on a package takes precedence if foo and bar both apply to the system. (Of course, it does say that keywords are always ARCHes, which would imply that only one could apply.) I think this all works as expected, however, except that a package having cross means that it is known to automatically work if you're cross-compiling, rather than simply meaning that it is known to work if you're cross-compiling and it would work if you were building natively on your target. -Daniel *This .sig left intentionally blank* -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [RFC] Mask packages that don't cross-compile
On Wed, 22 Nov 2006, Brian Harring wrote: On Wed, Nov 22, 2006 at 05:04:36PM -0500, Daniel Barkalow wrote: I wouldn't change ACCEPT_KEYWORDS at all or anything in the computation of pgroups or mygroups in portdbapi.gvisible(), so package.keywords is unchanged and the whole incremental ACCEPT_KEYWORDS is also unchanged. Find that a bit hard to believe frankly; inserting cross into a packages keywords _has_ to undergo the transformation somewhere. If you're not doing it there, then you're probably doing it somewhere that you shouldn't be ;) I'm not inserting cross into a package's keywords. I'm saying that perl ebuilds (for example) should have in their KEYWORDS -cross to indicate that they don't work with the cross keyword. The logic is the completely universal thing where a package puts its keywords in KEYWORDS, and the configuration has keywords in make.conf. The proper place for an ebuild to specify that it doesn't work when cross-compiling is, obviously, in the ebuild, since the maintainers obviously know, or can be told. With mainline emerge (and a locally-modified perl ebuild that adds -cross to KEYWORDS) and ACCEPT_KEYWORDS=cross, I get: mygroups = alpha amd64 arm hppa ia64 m68k mips ppc ~ppc-macos ppc64 s390 sh sparc ~sparc-fbsd x86 ~x86-fbsd -cross pgroups = arm cross The present documentation (Ebuild HOWTO, for example) says If the KEYWORDS flag has a preceding -, then the package does not work with the given keyword. But this is ignored by portage, because Packages that do not support the native architecture are automatically masked by Portage, which means that -x86 has no effect, because an ebuild with -x86 won't have x86 or ~x86, and is therefore masked. I'm proposing that -foo be taken seriously as meaning that the package does not work with the foo keyword, even if the ebuild would otherwise be visible. Why would you propose that? That's already the case as is, folks just have a way around it if they try hard enough (which isn't necessarily a bad thing). That is not the case currently. If a package has -foo (when the user has foo and doesn't have -foo), the ebuild still can pass the keyword check. E.g., if an ebuild has KEYWORDS=* -x86, it will be built on x86. In the example above, the package is not masked under the current implementation, because arm matches and -cross is completely ignored. Not seeing how that proposal is related to xcompile either. It's not specificly connected to xcompile. It just lets ebuilds specify negative keywords that have actual effects. It's just that I'm cross-compiling is a property that isn't tied to a particular profile and which a number of ebuilds could use to say this ebuild won't work for you. -Daniel *This .sig left intentionally blank* -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] [PATCH] Allow ROOT in non-/ make.conf
Let PORTAGE_CONFIGROOT/etc/make.conf, where PORTAGE_CONFIGROOT is not /,
specify ROOT.
In general, a set of configuration files other than the base set is
intended for a target root other than the live system. Normally, it is
intended for a particular target root. This patch allows make.conf in this
situation to specify the target root. A ROOT environment variable, if set,
overrides this setting (so the user can use a configuration that's
normally used for target A on target B, if desired).
This patch also postpones the setting of defaults for PORTAGE_CONFIGROOT
and ROOT until just before they are used, so that it is possible to
distinguish an emerge command with ROOT=/ from one without ROOT set.
Signed-off-by: Daniel Barkalow [EMAIL PROTECTED]
Index: pym/portage.py
===
--- pym/portage.py (revision 5090)
+++ pym/portage.py (working copy)
@@ -833,9 +833,15 @@
if not test or (str(test.__class__) != 'portage.config'):
raise TypeError, Invalid type for config object: %s %
test.__class__
+def check_var_directory(varname, var):
+ if not os.path.isdir(var):
+ writemsg(!!! Error: %s='%s' is not a directory. Please correct
this.\n % (var, varname),
+ noiselevel=-1)
+ raise portage_exception.DirectoryNotFound(var)
+
class config:
def __init__(self, clone=None, mycpv=None, config_profile_path=None,
- config_incrementals=None, config_root=/, target_root=/,
+ config_incrementals=None, config_root=None, target_root=None,
local_config=True):
self.already_in_regenerate = 0
@@ -921,17 +927,13 @@
# backupenv is for calculated incremental variables.
self.backupenv = os.environ.copy()
+ if not config_root:
+ config_root = /
+
config_root = \
normalize_path(config_root).rstrip(os.path.sep)
+ os.path.sep
- target_root = \
- normalize_path(target_root).rstrip(os.path.sep)
+ os.path.sep
- for k, v in ((PORTAGE_CONFIGROOT, config_root),
- (ROOT, target_root)):
- if not os.path.isdir(v):
- writemsg(!!! Error: %s='%s' is not a
directory. Please correct this.\n % (k, v),
- noiselevel=-1)
- raise
portage_exception.DirectoryNotFound(v)
+ check_var_directory(PORTAGE_CONFIGROOT, config_root)
self.depcachedir = DEPCACHE_PATH
@@ -1125,7 +1127,9 @@
noiselevel=-1)
sys.exit(1)
-
+ if config_root != / and ROOT in self.mygcfg and not
target_root:
+ target_root = self.mygcfg[ROOT]
+
self.configlist.append(self.mygcfg)
self.configdict[conf]=self.configlist[-1]
@@ -1156,6 +1160,14 @@
pass
del blacklisted, cfg
+ if not target_root:
+ target_root = /
+
+ target_root = \
+ normalize_path(target_root).rstrip(os.path.sep)
+ os.path.sep
+
+ check_var_directory(ROOT, target_root)
+
env_d = getconfig(
os.path.join(target_root, etc,
profile.env), expand=False)
# env_d will be None if profile.env doesn't exist.
@@ -7327,7 +7339,7 @@
commit_mtimedb(mydict=d, filename=self.filename)
self._clean_data = copy.deepcopy(d)
-def create_trees(config_root=/, target_root=/, trees=None):
+def create_trees(config_root=None, target_root=None, trees=None):
if trees is None:
trees = {}
else:
@@ -7345,11 +7357,11 @@
myroots = [(settings[ROOT], settings)]
if settings[ROOT] != /:
- settings = config(config_root=/, target_root=/,
+ settings = config(config_root=None, target_root=None,
config_incrementals=portage_const.INCREMENTALS)
settings.lock()
settings.validate()
- myroots.append((/, settings))
+ myroots.append((settings[ROOT], settings))
for myroot, mysettings in myroots:
trees[myroot] = portage_util.LazyItemsDict(trees.get(myroot,
None))
Index: bin/emerge
===
--- bin/emerge (revision 5090)
+++ bin
Re: [gentoo-portage-dev] [PATCH] --config-root command-line option
On Fri, 17 Nov 2006, Marius Mauch wrote: I prefer to have one way to do things, and the system for variables worked quite well so far. Adding CLI overrides on top of that seems not only redundant to me but also potentially confusing (which vars have CLI overrides? where in the incremental stack does the override fit in?). Add that to the already overloaded option system. This particular option clearly can't participate in the incremental stack at all, because it controls which set of config files you read the entire incremental stack out of. So that's not an issue. Besides, if you need this feature on a somewhat regular base it seems easier to me to just export the var once instead of specifying the option on the command line all the time (ok, using DEFAULT_OPTS avoids that, but then you have the same issues you listed above). config_root is useful primarily when there are multiple configurations that you use. Exporting it in your environment would be profoundly confusing, because then you have different shells that build the same packages differently, with no indication of what's going on. You'd surely end up installing qtopia on your workstation or firefox on your pda. To update your workstation you do: % emerge -pvutDN world To update your pda disk image you do: % emerge --config-root=/etc/pda -pvutDN world -Daniel *This .sig left intentionally blank* -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] [PATCH] Allow non-default make.conf to set ROOT
If PORTAGE_CONFIGROOT is not /, this is likely to mean that we're not intended to be working on the live system (and, in fact, are probably making stuff that's incompatible with the live system). The user probably wants to use ROOT, but we ought to let the make.conf in the PORTAGE_CONFIGROOT set ROOT, so there's only one variable that the user needs to keep straight. I could do a bit more extensive version to check the config file's ROOT (if present) for being a directory, like the environment variable is checked, and to make the environment variable override the config file, if either of those is worthwhile. Signed-off-by: Daniel Barkalow [EMAIL PROTECTED] Index: pym/portage.py === --- pym/portage.py (revision 5054) +++ pym/portage.py (working copy) @@ -1128,6 +1128,8 @@ noiselevel=-1) sys.exit(1) + if config_root != / and ROOT in self.mygcfg: + target_root = self.mygcfg[ROOT] self.configlist.append(self.mygcfg) self.configdict[conf]=self.configlist[-1] -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] [PATCH] --config-root command-line option
Allow PORTAGE_CONFIGROOT to be set as a command-line option. It can be
annoying to get environment variables to emerge, particularly when you
need sudo and you only want the environment variable some of the time.
Also cleans up parsing of options which have to be parsed before the
command line that includes EMERGE_DEFAULT_OPTS is assembled.
Signed-off-by: Daniel Barkalow [EMAIL PROTECTED]
Index: bin/emerge
===
--- bin/emerge (revision 5054)
+++ bin/emerge (working copy)
@@ -4193,6 +4193,26 @@
sys.stderr.write(!!! '%s' or '%s'\n\n % (action1, action2))
sys.exit(1)
+def parse_early_opts(cmdline):
+ early={}
+ normal=[]
+ for i in cmdline:
+ isearly = False
+ if i in [--ignore-default-opts]:
+ isearly = True
+ for opt in [--config-root]:
+ if i.startswith(opt + =):
+ isearly = True
+ if isearly:
+ if = in i:
+ idx = i.index(=)
+ early[i[:idx]] = i[idx+1:]
+ else:
+ early[i]=True
+ else:
+ normal.append(i)
+ return early, normal
+
def parse_opts(tmpcmdline):
myaction=None
myopts = {}
@@ -4286,10 +4306,12 @@
sys.exit(9)
del myroot, mysettings
-def load_emerge_config(trees=None):
+def load_emerge_config(trees=None, config_root=None):
kwargs = {}
for k, envvar in ((config_root, PORTAGE_CONFIGROOT),
(target_root, ROOT)):
kwargs[k] = os.environ.get(envvar, /)
+ if config_root:
+ kwargs[config_root] = config_root
trees = portage.create_trees(trees=trees, **kwargs)
settings = trees[/][vartree].settings
@@ -4389,12 +4411,19 @@
def emerge_main():
# Portage needs to ensure a sane umask for the files it creates.
os.umask(022)
- settings, trees, mtimedb = load_emerge_config()
+
+ earlyopts, normalopts = parse_early_opts(sys.argv[1:])
+
+ config_root_opt = None
+ if --config-root in earlyopts:
+ config_root_opt = earlyopts[--config-root]
+
+ settings, trees, mtimedb =
load_emerge_config(config_root=config_root_opt)
portdb = trees[settings[ROOT]][porttree].dbapi
if portage.global_updates(settings, trees, mtimedb[updates]):
mtimedb.commit()
# Reload the whole config from scratch.
- settings, trees, mtimedb = load_emerge_config(trees=trees)
+ settings, trees, mtimedb = load_emerge_config(trees=trees,
config_root=config_root_opt)
portdb = trees[settings[ROOT]][porttree].dbapi
ldpath_mtimes = mtimedb[ldpath]
@@ -4414,9 +4443,9 @@
nocolor()
tmpcmdline = []
- if --ignore-default-opts not in sys.argv:
+ if --ignore-default-opts not in earlyopts:
tmpcmdline.extend(settings[EMERGE_DEFAULT_OPTS].split())
- tmpcmdline.extend(sys.argv[1:])
+ tmpcmdline.extend(normalopts)
myaction, myopts, myfiles = parse_opts(tmpcmdline)
for myroot in trees:
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] Allow non-default make.conf to set ROOT (take 2)
(Previous version left ROOT from .../etc/make.conf unnormalized) If PORTAGE_CONFIGROOT is not /, this is likely to mean that we're not intended to be working on the live system (and, in fact, are probably making stuff that's incompatible with the live system). The user probably wants to use ROOT, but we ought to let the make.conf in the PORTAGE_CONFIGROOT set ROOT, so there's only one variable that the user needs to keep straight. Also normalize and check ROOT after reading the config file and getting this option. Still doesn't let environment variable (or, in general, callers of create_trees) override the config file. Signed-off-by: Daniel Barkalow [EMAIL PROTECTED] Index: pym/portage.py === --- pym/portage.py (revision 5054) +++ pym/portage.py (working copy) @@ -833,6 +833,12 @@ if not test or (str(test.__class__) != 'portage.config'): raise TypeError, Invalid type for config object: %s % test.__class__ +def check_var_directory(varname, var): + if not os.path.isdir(var): + writemsg(!!! Error: %s='%s' is not a directory. Please correct this.\n % (var, varname), + noiselevel=-1) + raise portage_exception.DirectoryNotFound(var) + class config: def __init__(self, clone=None, mycpv=None, config_profile_path=None, config_incrementals=None, config_root=/, target_root=/, @@ -929,12 +935,7 @@ target_root = \ normalize_path(target_root).rstrip(os.path.sep) + os.path.sep - for k, v in ((PORTAGE_CONFIGROOT, config_root), - (ROOT, target_root)): - if not os.path.isdir(v): - writemsg(!!! Error: %s='%s' is not a directory. Please correct this.\n % (k, v), - noiselevel=-1) - raise portage_exception.DirectoryNotFound(v) + check_var_directory(PORTAGE_CONFIGROOT, config_root) self.depcachedir = DEPCACHE_PATH @@ -1128,7 +1129,9 @@ noiselevel=-1) sys.exit(1) - + if config_root != / and ROOT in self.mygcfg: + target_root = self.mygcfg[ROOT] + self.configlist.append(self.mygcfg) self.configdict[conf]=self.configlist[-1] @@ -1179,6 +1182,12 @@ self[PORTAGE_CONFIGROOT] = config_root self.backup_changes(PORTAGE_CONFIGROOT) + + target_root = \ + normalize_path(target_root).rstrip(os.path.sep) + os.path.sep + + check_var_directory(ROOT, target_root) + self[ROOT] = target_root self.backup_changes(ROOT) -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Getting development version of portage
Is there some easy way to get read-only access to the repository, so that I can track it with svn? Or to get the latest revision as a whole, rather than downloading each file individually? -Daniel *This .sig left intentionally blank* -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] [PATCH] Replace --ask with --pretend if operation not allowed
If some operation requires root or portage access, and the user doesn't have it, and the --ask option is enabled, replace it with --pretend instead of aborting with an error. Also rearranges the test for required privs to eliminate the duplication of the consequences, which are not more than 2 lines. Applies to current trunk. Signed-off-by: Daniel Barkalow [EMAIL PROTECTED] Index: bin/emerge === --- bin/emerge (revision 5050) +++ bin/emerge (working copy) @@ -4571,15 +4571,17 @@ # We've already allowed --version and --help above. if --pretend not in myopts and \ myaction not in (search,info): - if portage.secpass = 1: - if --fetchonly not in myopts and \ - --fetch-all-uri not in myopts and \ - myaction not in (metadata, regen): + if portage.secpass 1 or \ + (--fetchonly not in myopts and \ +--fetch-all-uri not in myopts and \ +myaction not in (metadata, regen)): + if --ask in myopts: + myopts[--pretend] = True + del myopts[--ask] + print root access would be required... adding --pretend to options. + else: print emerge: root access required. sys.exit(1) - else: - print emerge: root access required. - sys.exit(1) disable_emergelog = False for x in (--pretend, --fetchonly, --fetch-all-uri): -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] [RFC] USE flags that don't affect package
It would be useful if ebuilds listed any USE flags that don't affect the package the ebuild is for, so that emerge knows it doesn't need to rebuild the package if these change (or are newly added to the ebuild). These include flags like glibc-compat20 and nptl on glibc-2.4-r3 (if they aren't set correctly, it just doesn't build, because this version doesn't support other configurations, but the USE flag is there so you don't blindly lose some obsolete feature you needed), or minimal on (e.g.) xinit (which affects RDEPEND, but not anything else). It's obviously not important for correctness, but it would save a whole lot of time, because it seems to be mostly big packages that end up with these, and ignoring them is a pain when you actually change a meaningful global USE flag and want to rebuild everything that's actually different. -Daniel *This .sig left intentionally blank* -- gentoo-portage-dev@gentoo.org mailing list
