| Summary: | Switches to modify emerge behavior during update/mergers | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | dE <de.techno> |
| Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | enhancement | CC: | esigra |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 300071 | ||
(In reply to comment #0) > There should be 2 switches, --update-upgradeable and --update-no-unmerge which > will be to {avoid updating of packages which will merge new packages} and > {packages which will unmerge other packages on upgrading} respectively. > What's the use case? Actually these features are present in aptitude (from Debian). I remember using it for production purpose, to avoid problems to the end user while doing a 'full upgrade'. In Gentoo, --update-upgradeable should avoid a major blocks and --update-no-unmerge will avoid removal of packages that the user needs, or to avoid a change of backends. Those are some pretty advanced features. We may have to re-write the dependency resolver from scratch. Well, now it's your choice... you are the devs. You may set this for low priority, since the amount of work it needs != the amount of advantage you get. However, this can provide advantage in server systems to provide a 'safe-upgrade' |
The latest portage automatically unmerges blocks and adds new packages to satisfies dependencies during updates. There should be 2 switches, --update-upgradeable and --update-no-unmerge which will be to {avoid updating of packages which will merge new packages} and {packages which will unmerge other packages on upgrading} respectively. Keep a note on build time dependencies (which should not be counted) using --update-upgradeable. Reproducible: Always Steps to Reproduce: