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

[Richard Purdie]

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.

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.

PREFERRED_PROVIDER is a build time thing. virtual/ is a build time
thing. How do I explain this any clearer?

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.

Cheers,

Richard