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
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.
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
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
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
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
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
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
, 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
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
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
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
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
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
14 matches
Mail list logo
