Summary: | sys-apps/portage: remove support for p.unmask in profiles/ | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Sebastian Luther (few) <SebastianLuther> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | esigra |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 385333, 386569 | ||
Bug Blocks: | 240187 |
Description
Sebastian Luther (few)
2011-10-02 08:25:40 UTC
To make clear what the actual problem is: If an overlay has profiles/package.unmask, which unmasks cat/pkg from this overlay, then it is not possible to mask cat/pkg from this overlay with /etc/portage/package.mask. This means that the overlays settings would take precedence over user settings, which is wrong. (There is a hack to get around this but the average user shouldn't have to know this.) Any updates on this? I see that the PMS 5.2.8 package.mask section documents negative package.mask atoms: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-510005.2.8 > Note that the -spec syntax can be used to remove a mask in > a parent profile, but not necessarily a global mask (from > profiles/package.mask, section 4.4). Maybe we should add a boolean flag to enable/disable package.unmask via repos.conf. I don't see any mention of package.unmask in PMS, so it seems like we could disable it by default. |