Gentoo Archives: gentoo-devhelp

From: "Sebastián Magrí" <sebasmagri@×××××.com>
To: Nikos Chantziaras <realnc@×××××.de>
Cc: gentoo-devhelp@l.g.o
Subject: Re: [gentoo-devhelp] Re: Writing ebuilds that replace others but with different name
Date: Sat, 26 Sep 2009 00:00:45
Message-Id: 1253923245.7405.2.camel@silversword
In Reply to: [gentoo-devhelp] Re: Writing ebuilds that replace others but with different name by Nikos Chantziaras
El sáb, 26-09-2009 a las 00:11 +0300, Nikos Chantziaras escribió:
> 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. > >
Then you will have to provide all the rdeps with alternative atom in depends I guess... Am I right?

Attachments

File name MIME type
signature.asc application/pgp-signature