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

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

[Nikos Chantziaras]

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?

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

[Justin]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Nikos Chantziaras]

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

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

[Justin]

[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]

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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

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

[Nikos Chantziaras]

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.

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

[Sebastián Magrí]

[-- Attachment #1: Type: text/plain, Size: 3359 bytes --]

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?

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Justin]

[-- Attachment #1: Type: text/plain, Size: 163 bytes --]

Sebastián Magrí wrote:
> 
> Why don't just use revision numbers? that's what I've always done...
> 
> 

You are right, revisions are completely enough.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]