On 09/24/2013 10:25 AM, Richard Purdie wrote:
On Mon, 2013-09-23 at 22:14 +0100, Richard Purdie wrote:
On Mon, 2013-09-23 at 21:01 +0200, David Nystrom wrote:
On Sep 23, 2013 8:01 PM, "Mark Hatle" <[email protected]>
wrote:
This looks to be the same as the 'native' package, but I don't think
you can just add a BBCLASSEXTEND = "nativesdk"
It mostly is and I cant, your right.
Why not? Just the SRC_URI or other issues?
Perhaps (in 1.6) someone should look at merging the three back
together.
Agree, the merged recipe will also get a bit messy, but probably
easier to maintain than in its current state.
If this is the same as the native version, I'd suggest adding a
comment stating as much so we can hopefully keep them in sync.
Will do, will return with v2
Well, I'm not happy with the idea of duplicating all this code.
shadow-native shouldn't exist and this makes things worse. With a few
minutes, I could write this patch:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=0730423fcda165a12112182b093d2f6df2f9c5eb
which at least makes the situation a bit less ugly. I guess I did spend
years doing these kinds of patches back when we had 50 versions of
everything and BBCLASSEXTEND didn't yet exist. With a few more minutes
perhaps I can get rid of the separate -native, now the differences are
clear. meld is a nice too for this kind of work btw.
Better still, a conversion to BBCLASSEXTEND:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&id=142d11b9b61bf18567cdb0527b7e63683c5afa1a
Thanks for that, I'll take above as a learning experience.
I'm have a question about this though.
diff --git a/meta/recipes-extended/shadow/shadow.inc
b/meta/recipes-extended/shadow/shadow.inc
index 4df5e5e..75b0afc 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
<snip>
+pkg_postinst_${PN} () {
+ if [ "x$D" != "x" ]; then
+ rootarg="--root=$D"
+ else
+ rootarg=""
+ fi
+
+ pwconv $rootarg
+ grpconv $rootarg
+}
<snip>
This will introduce the postinstall hook for both ${BPN}-native and
${BPN} ?. Before the change, the postinstall hook was activated only by
${BPN} afaict. Tried removing it from native* through
pkg_postinst_${BPN}, but that does not seem to work.
Hmm, slightly off-topic, but when looking at the postinstalls:
shadow:
cat /tmp/opkg-extract-574/CONTROL/postinst
if [ "x$D" != "x" ]; then
rootarg="--root=$D"
else
rootarg=""
fi
pwconv $rootarg
grpconv $rootarg
update-alternatives --install /usr/bin/passwd passwd
/usr/bin/passwd.shadow 200
update-alternatives --install /usr/bin/chfn chfn /usr/bin/chfn.shadow
200
update-alternatives --install /usr/bin/newgrp newgrp
/usr/bin/newgrp.shadow 200
Above is not a problem since OPKG_OFFLINE_ROOT in update-alternatives
can be used to redirect symlink creation when creating a from a package
repo.
nativesdk-shadow:
if [ "x$D" != "x" ]; then
rootarg="--root=$D"
else
rootarg=""
fi
pwconv $rootarg
grpconv $rootarg
update-alternatives --install
/opt/poky/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/passwd
passwd
/opt/poky/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/passwd.shadow
200
update-alternatives --install
/opt/poky/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/chfn chfn
/opt/poky/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/chfn.shadow 200
update-alternatives --install
/opt/poky/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/newgrp
newgrp
/opt/poky/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/newgrp.shadow
200
update-alternatives --install
/opt/poky/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/chsh chsh
/opt/poky/1.4+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/chsh.shadow 200
Could we not add a "--root" option to update-alternatives like done to
update-rc.d instead of hardcoding paths or using envs.
Also, seems like ${sysconfdir} in the nativesdk-opkg postinstall expands to:
chmod 0755 $D${sysconfdir}/rcS.d/S${POSTINSTALL_INITPOSITION}run-postinsts
chmod 0755
$D/opt/poky/1.4+snapshot/sysroots/x86_64-pokysdk-linux/etc/rcS.d/S98run-postinsts
Is this really expected behaviour ?
Br,
David
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
