[OE-core] [PATCH 03/22] update-alternatives.bbclass: Add missing runtime dependency

[Richard Purdie]

On Tue, 2012-12-04 at 19:47 -0600, Mark Hatle wrote:
> On 12/4/12 2:46 PM, Richard Purdie wrote:
> > On Tue, 2012-12-04 at 11:34 -0600, Mark Hatle wrote:
> > I keep telling people this and people keep ignoring me.
> >
> > We DO NOT SUPPORT switching providers at runtime since its a package
> > manager specific problem for which we currently have no general
> > abstraction.
> 
> We do support switching providers already, that's the whole alternatives system 
> itself.  What is different is in this case we can't use the update-alternatives.

We do support update alternatives, yes. We're talking about something
else here though.

> But with the RPROVIDE of update-alternatives within the dpkg and opkg code..  We 
> can certainly require 'update-alterantives' and the packaging systems will do 
> the right thing (they have so far...)

Ok, let me put this a different way. What exactly tells tells the
package manager what it should be installing as "update-alternatives"?
Where is the variable that controls this?

I think you will find there isn't any mechanism for it. The only reason
it does the right thing is a combination of:

a) We've configured things to only build one provider in most cases
b) We use the VIRTUAL-RUNTIME_update-alternatives substitution that 
   Martin mentions.

> > This leads to patches like:
> >
> > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=fe21ace36e19e06cbfdb83f73e60623bd4e382af
> >
> > since the virtual/ space does not somehow magically work at runtime,
> > worse it breaks the deb package backend.
> 
> It works in RPM... but if it doesn't in deb (and ipk) I understand the 
> limitations we are bound to.  Limiting the character space (i.e. no '/') is 
> different then saying we don't support RPROVIDES...

We support RPROVIDES, no argument. What we don't have is any mechanism
to indicate to *any* of the package managers that if there are two
providers, which one should be preferred.

The character was just a detail, the whole approach was also flawed, at
least as the system stands today :(.

> > PREFERRED_PROVIDER is a build time thing. virtual/ is a build time
> > thing. How do I explain this any clearer?
> 
> I'm still confused on the PREFERRED_PROVIDER honestly.

That much is clear from the email :/. It only works for build time
resolution, not package management.

> conf/distro/include/default-providers.inc:PREFERRED_PROVIDER_virtual/update-alternatives 
> ?= "update-alternatives-cworth"
> conf/distro/include/default-providers.inc:PREFERRED_PROVIDER_virtual/update-alternatives-native 
> ?= "opkg-native"
> 
> There is no 'update-alternatives-cworth' recipe.. but there is an opkg recipe 
> that happens to provide an update-alternatives-cworth -package-.  So does 
> PREFERRED_PROVIDER select packages or recipes?

It works in "build" namespace, namely DEPENDS and PROVIDES, so recipes.

Recipes can have additional PROVIDES other than their name, not to be
confused with RPROVIDES which is package namespace and separate.

We have no support for PREFERRED_RPROVIDER for example since that would
have to get communicated to the package manager. It would be interesting
to see that work...

> > The only mechanism for distro selection of runtime is VIRTUAL-RUNTIME_
> > which is pretty horrible and likely would be better done with something
> > debian package renaming like since we already have that mangling code.
> 
> And the VIRTUAL-RUNTIME isn't a runtime selection, it's a build-time selection. 

I realise that. As I said earlier, we don't support runtime selection
and we allow distro selection of some things (at build time) using this
rather ugly mechanism. I'd love to have something neater but its hard to
interface that into all the packaging backends.

>   If we need to select this at build-time, we can.

Rightly or wrongly, we need to.

>   I'm happy with changing the 
> patch, but as a distribution person I really don't care who provides this as 
> long as something does.

We care about deterministic builds so we have to care about details like
this.

Cheers,

Richard