Summary: | Strange update of configuration files | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Maciej Piechotka <uzytkownik2> |
Component: | Unclassified | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | esigra, jer, kingjon3377 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 376695 |
Description
Maciej Piechotka
2014-10-22 05:25:48 UTC
EMERGE_DEFAULT_OPTS="... --autounmask=n" I had to rush to disable this myself. It seems this is some kind of innovation in 2.2.14, even though the dependencies it picks are rarely the right ones. Maybe a =*/*-*9999* setting in /etc/portage/package.mask helps. Here is some documentation for a central function in the autounmask code: def _autounmask_levels(self): """ Iterate over the different allowed things to unmask. 0. USE 1. USE + license 2. USE + ~arch + license 3. USE + ~arch + license + missing keywords 4. USE + license + masks 5. USE + ~arch + license + masks 6. USE + ~arch + license + missing keywords + masks Some thoughts: * Do least invasive changes first. * Try unmasking alone before unmasking + missing keywords to avoid -9999 versions if possible """ I've seen cases where emerge prefers an unstable version over a USE flag change when: || ( unstable/atom stable/atom[foo] ) or where it prefers one USE flag change over another: || ( some/atom[bar] some/atom[foo] ) in favour of the earliest in order. This shouldn't be such a trivial choice for emerge to automatically make and then put in writing for the admin to rubberstamp, as it were. Or /does/ the order of appearance now denote a preference for the earlier (which is a point of contention in PMS AFAIK, with many paludis related bugs asking for a "proper" reordering)? |