| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Controllable via 'cache-format', currently it supports only one cache;
'pms', and defaults to it. If an unsupported cache-format is specified,
the cache is disabled. If pms is specified and metadata/cache directory
doesn't exist, the cache is disabled.
Finally, this rips out the best module support for locally overriding
the cache format used for pregenerated caches; this functionality made
zero sense (upstream determines the format, we use what is available).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it possible to disable the dynamic dependency updates that
FakeVartree performs by default.
WARNING: If --dynamic-deps is disabled, then it is necessary to
ensure that an alternative method is used to handle package moves
in dependencies of installed packages. Normally, this is handled
by FEATURES="fixpackages", which is enabled by default and may be
disabled via make.conf(5). Alternatively, in order to manually apply
package moves, run `emaint --fix moveinst` after each emerge --sync
operation (see emaint(1)).
|
|
|
|
| |
Bug #286201
|
| |
|
|
|
|
|
|
|
|
| |
The slot conflict display has better noise reduction than the
unsatisfied blockers display, so skip unsatisfied blockers display if
there are slot conflicts (see bug #385391). Note that this reverses
the logic from bug 159310, since the slot conflict display has evolved
a lot since then.
|
|
|
|
| |
This will fix bug #385413.
|
|
|
|
|
|
| |
This fixes a false --binpkg-respect-use warning that's triggered by
erroneous USE/IUSE comparison between the new-style virtual and an
old-style virtual match.
|
|
|
|
|
|
|
| |
This causes new-style virtuals to get pulled in for virtuals that are
already satisfied by installed old-style virtuals. This case is common,
due to PROVIDE being (removed without revision bump) from lots of
ebuilds.
|
| |
|
|
|
|
|
|
| |
Since the change involving slot conflict parent atoms in commit
6cea2091526659521d35be6c8dc7733f69f1a760, we want to check to make
sure we don't display any false positives in the "missed updates".
|
|
|
|
|
|
|
|
|
|
|
| |
This adds three states to layout.conf key use-manifest; false, true, and strict.
false means "don't use manifests at all"
true means "use and generate manifests, but allow them to be missing"
strict means "manifests must be used everywhere in this repo"
BUG=chromium-os:11308
TEST=repoman manifest usage.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
We don't want to check for --rebuilt-binaries here, unless --usepkg
is also enabled. In fact, we can skip the --rebuilt-binaries check
since people who really want to ensure that binary packages are used
as much as possible will typically specify --usepkgonly (or
--getbinpkgonly which implies --usepkgonly).
|
|
|
|
|
|
|
|
| |
If --binpkg-respect-use is not explicitly specified, we enable the
behavior automatically (like requested in bug #297549), as long as it
doesn't strongly conflict with other options that have been specified.
Strongly conflicting options currently include --usepkgonly and
--rebuilt-binaries.
|
|
|
|
|
| |
Explicitly stating --binpkg-respect-use=y will disable the ignored
binary warning. This will fix bug #297549.
|
| |
|
|
|
|
|
| |
Trigger the --complete-graph behavior if an installed package version will
change (upgrade or downgrade). This option is enabled by default.
|
| |
|
|
|
|
| |
See bug 379333.
|
|
|
|
|
|
|
| |
If backtracking masks a package that caused another package to
be masked, we declare this backtracking node as invalid. The
backtracker should be able to find another node that gives a
valid solution if one exists. This fixes bug 375573.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Currently emerge suggests --autounmask=n if any configuration
change is proposed. With this patch it will print a suggestion
only for mask changes, as these are the changes people complain
most about. It will suggest --autounmask-keep-masks in this case.
|
|
|
|
|
|
| |
Disables creation of p.unmask entries to allow users
to insist on their masks and hope for another conflict
resolution (i.e. missed update). This fixes bug 372485.
|
|
|
|
|
|
|
|
| |
The default behavior of --autounmask is now changed back to
the original one, namely to use '=' operators. The
--autounmask-unrestricted-atoms option allows the use of '>='
operators whenever possible. This addresses the issues raised
in bugs 372405, 374331 and 379333.
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes bug 375265.
|
|
|
|
|
|
|
| |
This provides depclean symmetry with the change in update behavior
from commit b95cbb6b78ad6d9b8e2d3edc5fafff122c3ce7c5, so that new
virtual slots won't be removed by depclean immediately after they
have been pulled in.
|
|
|
|
| |
This fixes the issue in bug #383269, comment #8.
|
| |
|
| |
|
|
|
|
|
| |
This enables controling the behaviour (creation and validation) per
repo, and while mildly ugly, refactors in the right direction.
|
|
|
|
|
|
|
|
| |
This re-implements the fix from commit
21330075f07248765016e104b3ba8216903f1ecb, without introducing the
unwanted behavior reported in bug 382557. This involves checking the
direct dependencies of virtual slot updates to make sure they are all
visible, before pulling them in.
|
|
|
|
|
|
| |
This reverts the behavior change from commit
21330075f07248765016e104b3ba8216903f1ecb, since it's too aggressive in
pulling in new virtual slots that may have masked dependencies.
|
|
|
|
|
|
|
| |
This re-implements the change from commit
21330075f07248765016e104b3ba8216903f1ecb in order to avoid executing
unnessary virtual slot expansion code when the given atom specifies a
slot or --update is enabled.
|
|
|
|
| |
This ensures that USE deps and repo deps are preserved here.
|
| |
|
|
|
|
|
|
|
|
| |
Previously, the virtual cost minimization code from bug #141118 would
prevent virtual dependencies from pulling in new slots. That behavior
was not desired for --update, so now it's fixed to pull in the latest
slot available. This allows virtual/jdk-1.7.0 to be pulled in by
dependencies when --update is enabled.
|
|
|
|
|
|
|
|
|
| |
This has been disabled since commit
c7faa634369e61b87a40172ceb0a5cb9494fd518, but the only reason cited
was to avoid permissions issues. So, go ahead and enable it, and handle
PermissionDenied just in case. NOTE: The NewsManager typically handles
permission errors by returning silently, so PermissionDenied won't
necessarily be raised even if we do trigger a permission error.
|
| |
|
| |
|
| |
|
| |
|