Re: [OE-core] [PATCH 1/1] (image|rootfs_ipk).bbclass, rootfs.py: ipk multilib fixes
On 13 February 2014 11:38, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Wed, 2014-02-12 at 17:40 +0200, Laurentiu Palcu wrote: On Wed, Feb 12, 2014 at 03:07:31PM +, Phil Blundell wrote: On Wed, 2014-02-12 at 16:55 +0200, Laurentiu Palcu wrote: * /usr/lib/opkg is where the alternatives go; Isn't that a bug? I'm far from being an expert in opkg or update-alternatives, but, looking in /usr/bin/update-alternatives I can see: # admin dir ad=$OPKG_OFFLINE_ROOT/usr/lib/opkg/alternatives Isn't that expected since the u-a provider is opkg-utils recipe? Its certainly desirable to have one set of alternatives files on a multilib system, not two. The variables/paths could probably do with being better however I've prefer not to trigger autobuilder failures on this until that gets resolved so I did take this. Cheers, Richard I should add some flexibility here. The problem is opkg-utils doesn't know what value OPKGLIBDIR has in the opkg recipe. It also isn't processed by a configure script to replace variables as it was in the opkg recipe. I'll have a think about a cleaner upgrade path for opkg and opkg-utils. I'd like to have a postinstall script compare the old and new OPKGLIBDIR paths and move data if needed. That would let me move everything from /usr/lib to /var/lib. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] (image|rootfs_ipk).bbclass, rootfs.py: ipk multilib fixes
On 14 February 2014 13:15, Paul Barker p...@paulbarker.me.uk wrote:
On 13 February 2014 11:38, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Wed, 2014-02-12 at 17:40 +0200, Laurentiu Palcu wrote:
On Wed, Feb 12, 2014 at 03:07:31PM +, Phil Blundell wrote:
On Wed, 2014-02-12 at 16:55 +0200, Laurentiu Palcu wrote:
* /usr/lib/opkg is where the alternatives go;
Isn't that a bug?
I'm far from being an expert in opkg or update-alternatives, but,
looking in /usr/bin/update-alternatives I can see:
# admin dir
ad=$OPKG_OFFLINE_ROOT/usr/lib/opkg/alternatives
Isn't that expected since the u-a provider is opkg-utils recipe?
Its certainly desirable to have one set of alternatives files on a
multilib system, not two. The variables/paths could probably do with
being better however I've prefer not to trigger autobuilder failures on
this until that gets resolved so I did take this.
Cheers,
Richard
I should add some flexibility here. The problem is opkg-utils doesn't
know what value OPKGLIBDIR has in the opkg recipe. It also isn't
processed by a configure script to replace variables as it was in the
opkg recipe.
Actually, OPKGLIBDIR is set in two places:
meta/classes/package_ipk.bbclass:
OPKGLIBDIR = ${localstatedir}/lib
meta/recipes-devtools/opkg/opkg.inc:
target_localstatedir := ${localstatedir}
OPKGLIBDIR = ${target_localstatedir}/lib
Should this be cleaned up so it's just set once globally and then we
can substitute that variable into the update-alternatives script
again?
--
Paul Barker
Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] (image|rootfs_ipk).bbclass, rootfs.py: ipk multilib fixes
On Wed, 2014-02-12 at 17:40 +0200, Laurentiu Palcu wrote: On Wed, Feb 12, 2014 at 03:07:31PM +, Phil Blundell wrote: On Wed, 2014-02-12 at 16:55 +0200, Laurentiu Palcu wrote: * /usr/lib/opkg is where the alternatives go; Isn't that a bug? I'm far from being an expert in opkg or update-alternatives, but, looking in /usr/bin/update-alternatives I can see: # admin dir ad=$OPKG_OFFLINE_ROOT/usr/lib/opkg/alternatives Isn't that expected since the u-a provider is opkg-utils recipe? Its certainly desirable to have one set of alternatives files on a multilib system, not two. The variables/paths could probably do with being better however I've prefer not to trigger autobuilder failures on this until that gets resolved so I did take this. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] (image|rootfs_ipk).bbclass, rootfs.py: ipk multilib fixes
On Wed, 2014-02-12 at 16:33 +0200, Laurentiu Palcu wrote:
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index 6d4f9fa..1887dd3 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -21,7 +21,7 @@ OPKG_POSTPROCESS_COMMANDS =
OPKGLIBDIR = ${localstatedir}/lib
-MULTILIBRE_ALLOW_REP = ${OPKGLIBDIR}/opkg
+MULTILIBRE_ALLOW_REP = ${OPKGLIBDIR}/opkg|/usr/lib/opkg
Why is that change needed? Doesn't this imply that ${OPKGLIBDIR} is
wrong?
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] (image|rootfs_ipk).bbclass, rootfs.py: ipk multilib fixes
On Wed, Feb 12, 2014 at 02:44:32PM +, Phil Blundell wrote:
On Wed, 2014-02-12 at 16:33 +0200, Laurentiu Palcu wrote:
diff --git a/meta/classes/rootfs_ipk.bbclass
b/meta/classes/rootfs_ipk.bbclass
index 6d4f9fa..1887dd3 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -21,7 +21,7 @@ OPKG_POSTPROCESS_COMMANDS =
OPKGLIBDIR = ${localstatedir}/lib
-MULTILIBRE_ALLOW_REP = ${OPKGLIBDIR}/opkg
+MULTILIBRE_ALLOW_REP = ${OPKGLIBDIR}/opkg|/usr/lib/opkg
Why is that change needed? Doesn't this imply that ${OPKGLIBDIR} is
wrong?
It's needed for the multilib sanity checks. I managed to make these
checks actually work in the new code and I had to adjust the directory
whitelist.
* ${OPKGLIBDIR}/opkg is for opkg's metadata and stuff;
* /usr/lib/opkg is where the alternatives go;
laurentiu
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] (image|rootfs_ipk).bbclass, rootfs.py: ipk multilib fixes
On Wed, 2014-02-12 at 16:55 +0200, Laurentiu Palcu wrote: * /usr/lib/opkg is where the alternatives go; Isn't that a bug? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] (image|rootfs_ipk).bbclass, rootfs.py: ipk multilib fixes
On Wed, Feb 12, 2014 at 03:07:31PM +, Phil Blundell wrote: On Wed, 2014-02-12 at 16:55 +0200, Laurentiu Palcu wrote: * /usr/lib/opkg is where the alternatives go; Isn't that a bug? I'm far from being an expert in opkg or update-alternatives, but, looking in /usr/bin/update-alternatives I can see: # admin dir ad=$OPKG_OFFLINE_ROOT/usr/lib/opkg/alternatives Isn't that expected since the u-a provider is opkg-utils recipe? laurentiu p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
