Summary: | package.provided - request for more elaboration and alternative suggestion | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Fabian Groffen <grobian> |
Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | fauli, grobian |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Other | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Fabian Groffen
2007-04-07 13:27:21 UTC
It violates all kinds of requirements for installed packages -- slot and use are simple examples. The alternative is to do things properly -- that is to say, when a package is depended upon, it needs to be installed. it's not too hard to extend package.provided down the line to support slot/use deps, thus enabling a way to inject flags/slot in... Re: "doing things properly", the point of package.provided is to avoid having to install crap ebuilds that do nothing. Need a wee bit more reasons then "It's not proper". Then a future specification can include a complete, proper solution. No point mandating support for yet another horrible hack for something that's being moved out of the tree anyway... (In reply to comment #3) > Then a future specification can include a complete, proper solution. No point > mandating support for yet another horrible hack for something that's being > moved out of the tree anyway... While that is sort of true, I still need it. And in that sense I agree package.mask isn't the best thing to do. All I want here is to know that a new-style-virtual isn't causing other problems, or that a use-based depend isn't adding as much as trouble as the package.mask is. Because that's essentially the way around this thing. And that doesn't feel like a much cleaner approach at first to me, and has to be added to each and every ebuild that uses it. You also need non-PMS things (prefix) for your whole port, no? In which case you're dependent upon Portage specifically anyway... If that is the opinion of the PMS-team then fine, but I still think the argumentation behind the deprecation in the version I've checked is rather weak and not very convincingly. However, if the PMS-team and I differ in opinion on that point, I see no reason to keep this bug alive any longer. Personally I'm in favour of WONTFIXing this and leaving the wording as-is. spb? I'm inclined to agree that this should be left out until a proper solution is worked out. Marking this as LATER to be resolved in a future version of the document. package.provided was dropped in EAPI 7. |