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

[Mark Hatle]

On 12/4/12 2:46 PM, Richard Purdie wrote:
> On Tue, 2012-12-04 at 11:34 -0600, Mark Hatle wrote:
>> On 12/4/12 11:04 AM, Martin Jansa wrote:
>>> On Tue, Dec 04, 2012 at 11:14:35AM -0600, Mark Hatle wrote:
>>>> When using update-alternatives, there should be a runtime dependency on
>>>> update-alternatives.  Without this, it's possible to get into a situation
>>>> where the package is not installable.
>>>>
>>>> Signed-off-by: Mark Hatle <mark.hatle at windriver.com>
>>>> ---
>>>>    meta/classes/update-alternatives.bbclass |    6 ++++++
>>>>    1 files changed, 6 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/meta/classes/update-alternatives.bbclass b/meta/classes/update-alternatives.bbclass
>>>> index 4e1ff27..e432506 100644
>>>> --- a/meta/classes/update-alternatives.bbclass
>>>> +++ b/meta/classes/update-alternatives.bbclass
>>>> @@ -304,6 +304,12 @@ python populate_packages_prepend () {
>>>>                alt_remove_links += '\tupdate-alternatives --remove  %s %s\n' % (alt_name, alt_target)
>>>>
>>>>            if alt_setup_links:
>>>> +            # RDEPENDS setup
>>>> +            bb.note('adding runtime requirement for update-alternatives for %s' % pkg)
>>>> +            rdepends = d.getVar('RDEPENDS_%s' % pkg, True) or ""
>>>> +            rdepends += ' ' + d.getVar('MLPREFIX') + 'update-alternatives'
>>>> +            d.setVar("RDEPENDS_%s" % pkg, rdepends)
>>>> +
>>>
>>> I guess you should use VIRTUAL-RUNTIME_update-alternatives here
>>
>> I believe what I have here is correct.
>
> No, Martin is right.
>
>>    We don't care which update-alternatives
>> we use, just that one is used.
>>
>> recipes-devtools/dpkg/dpkg.inc:RPROVIDES_update-alternatives-dpkg +=
>> "update-alternatives"
>> recipes-devtools/opkg/opkg.inc:RPROVIDES_update-alternatives-cworth +=
>> "update-alternatives"
>>
>> If I use the ${VIRTUAL-RUNTIME_update-alternatives} that has the effect or hard
>> coding which specific version of update-alternatives we're going to use.. (-dpg
>> vs -cworth)  I'm not sure this is really the desired behavior in this case -- if
>> it is, it's easy enough to change of course.
>
> 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.

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

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

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

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?

> 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. 
  If we need to select this at build-time, we can.  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.

--Mark

> Cheers,
>
> Richard
>
>