Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-devhelp
Navigation:
Lists: gentoo-devhelp: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-devhelp@g.o
From: Nikos Chantziaras <realnc@...>
Subject: Re: Writing ebuilds that replace others but with different name
Date: Fri, 25 Sep 2009 00:00:27 +0300
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



Replies:
Re: Re: Writing ebuilds that replace others but with different name
-- Justin
References:
Writing ebuilds that replace others but with different name
-- Nikos Chantziaras
Re: Writing ebuilds that replace others but with different name
-- Justin
Navigation:
Lists: gentoo-devhelp: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Writing ebuilds that replace others but with different name
Next by thread:
Re: Re: Writing ebuilds that replace others but with different name
Previous by date:
Re: Writing ebuilds that replace others but with different name
Next by date:
Re: Re: Writing ebuilds that replace others but with different name


Updated Jun 03, 2012

Summary: Archive of the gentoo-devhelp mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.