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?