| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
For API consumers that call this function without the vardbapi
parameter, it whould continue to work correctly in all the cases
that worked before the vardbapi was added.
|
| |
|
| |
|
| |
|
|
|
|
| |
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 will handle the issue reported in bug #383269, comment #5.
|
|
|
|
| |
This fixes the issue in bug #383269, comment #8.
|
|
|
|
| |
This fixes the issue in bug #383269, comment #3.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
These checks never really needed, and they are not valid for thin
manifests or allow-missing-manifests.
|
|
|
|
|
| |
With thin manifest, there's no need to have a Manifest file if there
are no DIST entries.
|
|
|
|
|
| |
With thin manifest, there's no need to have a Manifest file if there
are no DIST entries.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This allows repos to disable manifest signatures, which is useful if
they want to prevent merge conflicts like those that thin-manifests is
designed to prevent.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
For any repo that wants thin (just src_uri digests), they just need to add
thin-manifests = true
to their layout.conf. Again, this should only be used in repositories
were the backing vcs provides checksums for the ebuild data.
|
|
|
|
|
|
| |
'thin' is just distfiles. This is primarily useful when the ebuild
lives in a vcs- git for example, which already has it's own checksums
to rely on.
|
|
|
|
|
| |
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, we used sys.getfilesystemencoding() for the 'merge'
encoding, but that had various problems:
1) If the locale is ever changed then it can cause orphan files due
to changed character set translation.
2) Ebuilds typically install files with utf_8 encoded file names,
and then portage would be forced to rename those files to match
sys.getfilesystemencoding(), possibly breaking things.
3) Automatic translation between encodings can lead to nonsensical
file names when the source encoding is unknown by portage.
4) It's inconvenient for ebuilds to convert the encodings of file
names themselves, and upstreams typically encode file names with
utf_8 encoding.
So, instead of relying on sys.getfilesystemencoding(), we avoid the above
problems by using a constant utf_8 'merge' encoding for all locales, as
discussed in bug #382199 and bug #381509.
|