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