Gentoo Archives: gentoo-devhelp

From: "Sebastián Magrí" <sebasmagri@×××××.com>
To: Justin <justin@×××××××××.net>
Cc: gentoo-devhelp@l.g.o
Subject: Re: [gentoo-devhelp] Re: Writing ebuilds that replace others but with different name
Date: Fri, 25 Sep 2009 20:40:49
In Reply to: Re: [gentoo-devhelp] Re: Writing ebuilds that replace others but with different name by Justin
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). > > > > 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. >
Why don't just use revision numbers? that's what I've always done...