Summary: | please let portage implicit mask ebuilds, which depend on masked ebuilds | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Carsten Lohrke (RETIRED) <carlo> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Carsten Lohrke (RETIRED)
2004-04-01 01:26:16 UTC
The problem then becomes how to make it clear that what portage is about to install is p.masked. We tend to not automate things like that because then people unmask things willy nilly, and especially p.masked packages, they are masked for a reason. The real question is how to make it so that people who want a better tool to do the unmasking ( which I would agree with, it does get annoying especiall with mono ;) ) without giving people who don't know what they are doing a tool to hang themselves with. Alec, please don't muddle that. I want to mask implicitly, which would be a nice feature to deal with slotted packages and their dependecies, when you don't want to have the stable slot X+1 package installed. I don't want to unmask implitly - or "willy nilly" as you say. This... likely ain't going to happen. If someone horks the tree by masking a required dependency, we slap them. Detecting, backtracking, and lieing to the user that a package isn't available cause one of it's deps is masked doesn't seem right... Re-open if you disagree/have an approach to this that can be sanely implemented :) |