From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] packagegroup: Add init-manager sanity check
Date: Thu, 18 Apr 2013 13:11:58 +0100 [thread overview]
Message-ID: <1366287118.10502.58.camel@ted> (raw)
In-Reply-To: <lywqs0xgv7.fsf@ensc-virt.intern.sigma-chemnitz.de>
On Thu, 2013-04-18 at 12:39 +0200, Enrico Scholz wrote:
> Richard Purdie <richard.purdie@linuxfoundation.org> writes:
>
> >> > Currently, you can set VIRTUAL-RUNTIME_init_manager to an init
> >> > system that isn't in DISTRO_FEATURES. This leads to head scratching
> >> > over unbootable images.
> >>
> >> Because this sanity check is placed into an anonymous function, this
> >> change affects also images which do not not include packagegroup-core*
> >> in their images and are not using VIRTUAL-RUNTIME_init_manager at all.
> >
> > Affects in that it runs the anonymous python fragment but does nothing?
>
> no; the 'parsing recipes' phase throws an exceptions
>
> | ERROR: Please ensure that your setting of VIRTUAL-RUNTIME_init_manager (sysvinit) matches the entries enabled in DISTRO_FEATURES## | ETA: 00:00:14
> | ERROR: Unable to parse /srv/oe/dev/org.openembedded.core/meta/recipes-extended/packagegroups/packagegroup-core-basic.bb: Exited with "1"
> | ERROR: Command execution failed: Exited with 1
>
>
> Of course, I can BBMASK out these packagegroup-core recipes or simply
> define VIRTUAL-RUNTIME_init_manager.
Hmm, I understand now.
The way I see this is that the system can't know if anything in your
environment is going to use packagegroup-* or not. Given that, I do
think this is a valid warning since whilst you know not to use them,
others may not.
> > Other proposals for solutions are welcome. I thought it better to
> > catch a common user misconfiguration than generate broken images
> > silently though.
>
> You can put this check into e.g. do_configure[prefuncs].
So it errors at build time some time later? Where we can is it not
better to inform the user of configuration issues earlier?
Cheers,
Richard
next prev parent reply other threads:[~2013-04-18 12:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-17 15:19 [PATCH] packagegroup: Add init-manager sanity check Richard Purdie
2013-04-18 10:19 ` Enrico Scholz
2013-04-18 10:28 ` Richard Purdie
2013-04-18 10:39 ` Enrico Scholz
2013-04-18 12:11 ` Richard Purdie [this message]
2013-04-18 12:25 ` Enrico Scholz
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=1366287118.10502.58.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=enrico.scholz@sigma-chemnitz.de \
--cc=openembedded-core@lists.openembedded.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.