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 <[email protected]>
> >> ---
> >> 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
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
