[oe] python skills and bug 2412

[Richard Purdie]

On Tue, 2007-11-27 at 15:43 +0200, Paul Sokolovsky wrote:
> Tuesday, November 27, 2007, 2:22:35 PM, you wrote:
> > On Mon, 2007-11-26 at 17:55 +0100, Robert Schuster wrote:
> > I commented on the bug but I will repeat here for wider exposure.
> 
> > "The real problem here is that virtual/libx11 should not be appearing in
> > the package manager namespace. RPROVIDES = "virtual/libx11" is plain
> > wrong and is the real bug."
> 
>   What exactly is wrong? RPROVIDES or "virtual/" or maybe "/" after
> all?

The whole idea. Using the virtual namespace in a runtime Provides is
meaningless.

This is not to be confused with PROVIDES = "virtual/*" which are
perfectly fine.

> > I've discussed this on the mailing list in the past, virtual/* shouldn't
> > ever be ending up in the runtime namespaces :/.
> 
>   And why is this? Virtual packages aka services aka facilities are
> core feature of flexible package management. IMHO, they are heavily
> underused in the current OE, which disallows creation of flexible,
> adaptable, and at the same time, consistent systems.

It doesn't work in OE as things stand which is why its underused. There
are at least two problems I can think of offhand:

a) When you compile a package against libx11 does it end up with a
Dependencies: libx11 or virtual/libx11? The answer is the former. This
means you can't switch between different providers "on device". This
means that a given distro must use one provider or the other and that
virtual/* in the runtime package management namespace is just plain
dangerous. If a distro doesn't do this, they will end up breaking their
feeds.

b) There is no way for bitbake's choices of providers to be passed to
the package manager. When faced with two virtual/libx11 packages, which
one should the package manager choose? The only possible solution at the
moment is not to get into that position or you end up with randomness in
builds (very bad). Packaged Staging could potentially help with this
FWIW. The same problem also exists in feeds which devices are accessing
so its not just isolated to the bitbake/package manager interface.

Yes, there may be ways OE/bitbake could be enhanced to do clever things
with virtual runtime namespaces but we have no current support for it
and shouldn't pretend otherwise. If someone wants to implement that, I'm
more than happy to look at, discuss and review a proposal but currently
it won't work.

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?

Cheers,

Richard