[oe] Build-time vs run-time virtuals, was: Re: python skills and bug 2412

[Paul Sokolovsky]

Hello Richard,

Tuesday, November 27, 2007, 5:05:42 PM, you wrote:

> On Tue, 2007-11-27 at 16:17 +0200, Paul Sokolovsky wrote:
>> > On Tue, 2007-11-27 at 15:43 +0200, Paul Sokolovsky wrote:
>> > A proper use for RPROVIDES is for something like gtk+-directfb to
>> > RPROVIDE gtk+. If an app linked against one, it should be able to run
>> > against the other (I'm assuming thats the case, if its not there
>> > shouldn't be an RPROVIDES).
>> 
>> > Does that help explain things?
>> 
>>   Ok, in other words, you say that OE's, build-time, virtuals, are
>> completely different thing than package manager's Provides facilities,
>> also common called virtuals? 

> Yes.

[]

> Indeed. Thinking about this stuff makes my head hurt :).

> PROVIDES + virtual/* = good
> RPROVIDES + virtual/* = nightmare + bug

> My point was that any of the latter will never do what people want/need
> and should be removed. If we ever do that, we should use a namespace
> other than "virtual" too.

  Yes, thought about namespace came to my mind too. I wonder, if
there're any ideas regarding that. Indeed, reusing "virtual-" prefix
while being familiar, would be confusing ;-(. Any ideas about another
standard prefix, or there would be adhoc naming conventions? From the
examples given, at least sometimes it makes sense to use prefix-less
Provides names:

gtk+ - real package, also implicitly provides gtk+
gtk+-directfb - real packages, Provides gtk+

Or infamous libxine. I envision it should be:

libxine-x11, Provides libxine
libxine-qpe, Provides libxine

(The problem here is that actually built package will be linked
against real package, and thus would apparently pull its name via
shlib dependencies).

> Cheers,

> Richard



-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com