The use of package.provided is strongly deprecated in current PMS. It is in use in the default-darwin profile, and beyond that in some overlays. The argumentation behind the deprecation of package.provided is a bit short and does some hand waving on severe adverse effects. My best guess is that this is a hint towards package.provided entries for instance not being considered in the has_version function. Some elaboration on this point would be nice to back up the deprecation. Next to this deprecation, since it is in use, I'd like it when PMS would suggest an alternative for package.provided which is better. I was thinking on this point whether a new style virtual package would do. This, however, requires for each package used like this a virtual to exist. I don't know if this is desirable for things like sys-apps/shadow. Reproducible: Always Steps to Reproduce:
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.
