Nikos Chantziaras schrieb:
> On 09/24/2009 11:38 PM, Justin wrote:
>> Nikos Chantziaras wrote:
>>> I seem to have some fundamental "flaw" in portage.  It seems I am not
>>> able to write an ebuild that will in effect be able to replace another
>>> one but with a different name.
>>>
>>> With RPMs, no matter how the RPM is named, it has "provides" data in it.
>>>   Is there some similar mechanism in portage?  It seems to me that if
>>> the
>>> name of an ebuild is changed, then *all* ebuilds depending on it will
>>> have to change too.  That looks like a PITA to me if it's true.
>>>
>>> For example, if I have an overlay that provides alternative/altered
>>> packages of already existing ones in the portage tree, they will "clash"
>>> with portage.  Let's assume that my overlay provides an ebuild called
>>> "foo-alt" which is a variation of a package in portage called "foo", but
>>> is totally compatible with it.  What I'm looking for is being able to
>>> emerge "foo-alt", but have the ebuild state clearly that it provides the
>>> "foo" dependency, so ebuilds depending on "foo" will be satisfied if
>>> "foo-alt" is installed but "foo" isn't.
>>>
>>> Possible?
>>>
>>>
>> Thats's what virtuals are good for. As an example see virtual/jre.
>> But in principle you are right. renaming a package is a headache and
>> should really be avoided.
> 
> I'm not sure how I can use virtuals to provide an alternative but
> completely compatible package.  I'll give a straight example:
> 
> In my overlay, there's "x11-libs/qt-opengl-alt".  It is a variation of
> qt-opengl, providing and *replacing* all files in it.  However, if I
> unmerge qt-opengl and install qt-opengl-alt instead, even though the
> installed packages depending on qt-opengl work perfectly fine with it
> (it's fully compatible), an "emerge -uDN world" will try to pull
> qt-opengl back in because it thinks it's missing (and this will of
> course result in a file collision since qt-opengl-alt is also installed,
> providing the same files).
> 
> Changing the category also doesn't help ("x11-libs-alt/qt-opengl" for
> example).
> 
> So virtuals don't seem to have anything to do with with my problem.
> What's missing is something like RPM's "provides" (so the qt-opengl-alt
> ebuild would be able to say "I provide the qt-opengl package.)  From
> your answer, I take it that portage doesn't offer anything like this and
> the ebuild's name is hardcoded to be the package it provides :P
> 
> 
Thats right, the only thing what you can do, is naming your ebuild
x11-libs/qt-opengl as well and give it higher version number as the one
in the tree.