On 1 October 2013 04:52, Martin Vaeth <va...@mathematik.uni-wuerzburg.de>wrote:
> > For instance, if you have your home-brewn version of program X, > you can just install the version under its own package name Y and > make it satisfy all dependencies of X. > (Currently you have to mess around with package.provided which has > many drawbacks like e.g. problems with USE-dependencies and, > moreover, you cannot publish Y in an overlay without requiring > that the user of that overlay modifies his package.provided manually.) Here, this is even more annoying, because as long as this inverse dependency is regulated by the eclass, even ebuilds in alternative trees are out of luck from being seen as candidates for an multi-way provided dependency, at least, you'd have to modify the eclass "somehow" This is something a native PROVIDES= implementation is not limited by. Though I reapeat, I do not want PROVIDES="perl-core/Foo-Bar", because thats going to have us the same problem, as it declares provides only on the granularity of *packages* not the granulatiry of files/modules. I'd be championing something more like ( but not nessecarily exactly like ) PROVIDES="cpan-module://Module::Build/4.5" Borrowing terms from the metadata.xml information, and the use of a per-token-type protocol prefix allows for multiple unambiguous namespaces that are not bound to the cat/package layout. And here, the semantics after "://" could be implemented differently if nessecary. Consuming code would just say DEPEND="cpan-module://Module::Build" or DEPEND=">=cpan-module://Module::Build/4.0" Though I don't know. The real problem is that as convenient as a PROVIDES= interface may be, doing it performantly could be a nightmare, and portage would probably need some sort of PROVIDES cache to even support such a feature efficiently. ( Which is basically what my solution offers, just with a developer-side-cache-generation instead of user-side-caching ) -- Kent
