1 |
El vie, 25-09-2009 a las 15:35 +0200, Justin escribió: |
2 |
> Nikos Chantziaras schrieb: |
3 |
> > On 09/24/2009 11:38 PM, Justin wrote: |
4 |
> >> Nikos Chantziaras wrote: |
5 |
> >>> I seem to have some fundamental "flaw" in portage. It seems I am not |
6 |
> >>> able to write an ebuild that will in effect be able to replace another |
7 |
> >>> one but with a different name. |
8 |
> >>> |
9 |
> >>> With RPMs, no matter how the RPM is named, it has "provides" data in it. |
10 |
> >>> Is there some similar mechanism in portage? It seems to me that if |
11 |
> >>> the |
12 |
> >>> name of an ebuild is changed, then *all* ebuilds depending on it will |
13 |
> >>> have to change too. That looks like a PITA to me if it's true. |
14 |
> >>> |
15 |
> >>> For example, if I have an overlay that provides alternative/altered |
16 |
> >>> packages of already existing ones in the portage tree, they will "clash" |
17 |
> >>> with portage. Let's assume that my overlay provides an ebuild called |
18 |
> >>> "foo-alt" which is a variation of a package in portage called "foo", but |
19 |
> >>> is totally compatible with it. What I'm looking for is being able to |
20 |
> >>> emerge "foo-alt", but have the ebuild state clearly that it provides the |
21 |
> >>> "foo" dependency, so ebuilds depending on "foo" will be satisfied if |
22 |
> >>> "foo-alt" is installed but "foo" isn't. |
23 |
> >>> |
24 |
> >>> Possible? |
25 |
> >>> |
26 |
> >>> |
27 |
> >> Thats's what virtuals are good for. As an example see virtual/jre. |
28 |
> >> But in principle you are right. renaming a package is a headache and |
29 |
> >> should really be avoided. |
30 |
> > |
31 |
> > I'm not sure how I can use virtuals to provide an alternative but |
32 |
> > completely compatible package. I'll give a straight example: |
33 |
> > |
34 |
> > In my overlay, there's "x11-libs/qt-opengl-alt". It is a variation of |
35 |
> > qt-opengl, providing and *replacing* all files in it. However, if I |
36 |
> > unmerge qt-opengl and install qt-opengl-alt instead, even though the |
37 |
> > installed packages depending on qt-opengl work perfectly fine with it |
38 |
> > (it's fully compatible), an "emerge -uDN world" will try to pull |
39 |
> > qt-opengl back in because it thinks it's missing (and this will of |
40 |
> > course result in a file collision since qt-opengl-alt is also installed, |
41 |
> > providing the same files). |
42 |
> > |
43 |
> > Changing the category also doesn't help ("x11-libs-alt/qt-opengl" for |
44 |
> > example). |
45 |
> > |
46 |
> > So virtuals don't seem to have anything to do with with my problem. |
47 |
> > What's missing is something like RPM's "provides" (so the qt-opengl-alt |
48 |
> > ebuild would be able to say "I provide the qt-opengl package.) From |
49 |
> > your answer, I take it that portage doesn't offer anything like this and |
50 |
> > the ebuild's name is hardcoded to be the package it provides :P |
51 |
> > |
52 |
> > |
53 |
> Thats right, the only thing what you can do, is naming your ebuild |
54 |
> x11-libs/qt-opengl as well and give it higher version number as the one |
55 |
> in the tree. |
56 |
> |
57 |
|
58 |
Why don't just use revision numbers? that's what I've always done... |