From: "David Nyström" <david.c.nystrom@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] shadow: Create recipe nativesdk-shadow
Date: Wed, 25 Sep 2013 14:24:23 +0200 [thread overview]
Message-ID: <5242D5F7.1000509@gmail.com> (raw)
In-Reply-To: <1380103400.18603.318.camel@ted>
On 09/25/2013 12:03 PM, Richard Purdie wrote:
> On Tue, 2013-09-24 at 16:30 +0200, David Nyström wrote:
>> 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.
>
> Basically the postinst is ignored for the -native version. It never gets
> packaged so isn't relevant. Adding in special cases for native for each
> and every recipe would get ugly very quickly.
>
Sorry, bad wording on my end. I was worried about nativesdk
post/prefuncs beeing added.
<snip>
>> 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 ?
>
> nativesdk postinstalls are probably badly handled at the moment.
I Agree, it would be good with a consistent handling between nativesdk
and target pre/postinstall hooks.
I'll try to dive into this subject when I have more time.
> I suspect if things can run at rootfs creation time they work out, if they
> can't run then, they never happen at all. We don't have a "first boot"
> of the sdk...
> Cheers,
>
> Richard
>
next prev parent reply other threads:[~2013-09-25 12:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-23 16:33 [PATCHv3] makedevs: add nativesdk to BBCLASSEXTENDS David Nyström
2013-09-23 16:34 ` [PATCH] shadow: Create recipe nativesdk-shadow David Nyström
2013-09-23 18:01 ` Mark Hatle
2013-09-23 19:01 ` David Nystrom
2013-09-23 21:14 ` Richard Purdie
2013-09-24 8:25 ` Richard Purdie
2013-09-24 14:30 ` David Nyström
2013-09-25 10:03 ` Richard Purdie
2013-09-25 12:24 ` David Nyström [this message]
2013-09-23 16:34 ` [PATCHv2] libpam: Avoid host contamination issue w. libprelude David Nyström
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5242D5F7.1000509@gmail.com \
--to=david.c.nystrom@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.