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

[Sebastián Magrí]

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...