Summary: | sys-apps/portage-2.3.8 --autounmask-continue doesn't factor for USE= in ENV and creates broken dep graphs | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Kent Fredric (IRC: kent\n) (RETIRED) <kentnl> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | esigra, pacho |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 376695 | ||
Attachments: | more context |
Description
Kent Fredric (IRC: kent\n) (RETIRED)
2017-10-29 13:18:54 UTC
Since USE settings in the environment will always override any package.use changes that --autounmask attempts to create, it's possible to create conflicts like this. I suppose the best --autounmask can to is to detect the conflict and report an error. USE settings in the environment can be treated similarly to use.force and use.mask settings. Rather than treat the USE environment like use.force/use.mask, it would be more flexible to convert it to a package.use "*/* ${USE}" setting that autounmask would be able override for specific packages when necessary. But package.use "*/* ${USE}" settings do not override settings for specific packages that came earlier in the package.use file(s) (ordered_by_atom_specificity function), so that won't always give the behavior expected for USE environment settings. I think what it should do is fold the environment USE settings into generated package.use settings for specific packages when needed, and then delete the USE variable from the environment that when the config is reloaded the generated package.use settings will give the intended result. |