[gentoo-devhelp] Re: Writing ebuilds that replace others but with different name

[Nikos Chantziaras]

On 09/25/2009 10:49 PM, Sebastián Magrí wrote:
> El vie, 25-09-2009 a las 15:35 +0200, Justin escribió:
>> 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).
>>>  [...]
>> 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.
>
> Why don't just use revision numbers? that's what I've always done...

Because if a higher version shows up in portage, it will be updated to 
that one.

The only thing that seems to help is to prefix it with an insanely high 
number, like "qt-opengl-99.4.5.2".  However, this has the drawback that 
it only works for just one overlay.  It's just a kludge.  It's actually 
the same package, just a different version of it.  The fundamental 
problem of being unable to provide* alternative packages that are easy 
to use by end users isn't solved.

* Note that the focus is on "provide" to others, not "use" myself.