1 |
Nikos Chantziaras wrote: |
2 |
> I seem to have some fundamental "flaw" in portage. It seems I am not |
3 |
> able to write an ebuild that will in effect be able to replace another |
4 |
> one but with a different name. |
5 |
> |
6 |
> With RPMs, no matter how the RPM is named, it has "provides" data in it. |
7 |
> Is there some similar mechanism in portage? It seems to me that if the |
8 |
> name of an ebuild is changed, then *all* ebuilds depending on it will |
9 |
> have to change too. That looks like a PITA to me if it's true. |
10 |
> |
11 |
> For example, if I have an overlay that provides alternative/altered |
12 |
> packages of already existing ones in the portage tree, they will "clash" |
13 |
> with portage. Let's assume that my overlay provides an ebuild called |
14 |
> "foo-alt" which is a variation of a package in portage called "foo", but |
15 |
> is totally compatible with it. What I'm looking for is being able to |
16 |
> emerge "foo-alt", but have the ebuild state clearly that it provides the |
17 |
> "foo" dependency, so ebuilds depending on "foo" will be satisfied if |
18 |
> "foo-alt" is installed but "foo" isn't. |
19 |
> |
20 |
> Possible? |
21 |
> |
22 |
> |
23 |
Thats's what virtuals are good for. As an example see virtual/jre. |
24 |
But in principle you are right. renaming a package is a headache and |
25 |
should really be avoided. |