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