All of lore.kernel.org
 help / color / mirror / Atom feed
From: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] packagegroup: Add init-manager sanity check
Date: Thu, 18 Apr 2013 14:25:09 +0200	[thread overview]
Message-ID: <lysj2oxbyy.fsf@ensc-virt.intern.sigma-chemnitz.de> (raw)
In-Reply-To: <1366287118.10502.58.camel@ted> (Richard Purdie's message of "Thu, 18 Apr 2013 13:11:58 +0100")

Richard Purdie <richard.purdie@linuxfoundation.org> writes:

>> 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.

Exactly; at this stage, the system does not known whether
VIRTUAL-RUNTIME_init_manager will ever be used and should not check it
there hence.


> Given that, I do think this is a valid warning

It's not a warning, but an error stopping the build


>> > 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?

The differrence is that the anonymous python function fails regardless
whether VIRTUAL-RUNTIME_init_manager is used or not (and can not cause
problems hence).

The check in do_configure() will fail only, when it is really used.

I know that the check in the anonymous python function is executed very
early while the do_configure() check might trigger hours later.  I do
not know whether such early warnings are really important; perhaps my
initial

| DEPENDS += "${@some_check(d)}"

suggestion could be enhanced so that some_check() throws an exception
and puts a note like the actual one.


Enrico



      reply	other threads:[~2013-04-18 12:42 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
2013-04-18 12:25         ` Enrico Scholz [this message]

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=lysj2oxbyy.fsf@ensc-virt.intern.sigma-chemnitz.de \
    --to=enrico.scholz@sigma-chemnitz.de \
    --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.