From: Rolf Leggewie <no2spam@nospam.arcornews.de>
To: openembedded-devel@openembedded.org
Subject: Re: [RFC] policy about nonworking recipes
Date: Fri, 22 May 2009 00:59:46 +0200 [thread overview]
Message-ID: <gv4md5$jmq$1@ger.gmane.org> (raw)
In-Reply-To: <gv4i2t$90h$1@ger.gmane.org>
Koen,
we're still discussing to find a good solution. No need to get all
worked up yet and calling other people pendantic[sic]. Is it really too
much to ask that the data in OE should generally be such that "bitbake
$target" at least builds?
If the distribution's settings are responsible for a build failing then
it's the distribution's responsibility to fix this. The pulseaudio and
autoconf example you gave is essentially bug 3722 but can otherwise be
handled. BTW, the workflow you then described is not what I'm suggesting.
My intention is not to abuse COMPATIBLE_MACHINE if that is not the right
place. I can only go by the well-defined meaning in the documentation
which at least does not mention build-time vs. run-time.
conf/documentation.conf:COMPATIBLE_MACHINE[doc] = "A regular expression
which matches the MACHINES support by the package/file. Failure to match
will cause the file to be skipped by the parser." IMHO setting it to an
empty string to indicate that no compatible machines are (currently!)
known does not conflict with that.
It would get people talking to fix the problem if there was still
interest, "git log" would stay meaningful, the recipe remains in the
place where people would be looking for it, etc.pp. Lots of good
reasons, I think, even if in the end it turned out that
s/autoconf/autoconf >= X.Y/ is what was really necessary.
To make it clear, my suggestion is not that every dev should immediately
set this when something does not compile. First of all, the "core stuff
needs review"-rule still applies, so we're mostly talking normal
packages here. Furthermore, this is a suggestion for stuff that would
otherwise be a candidate for recipes/nonworking, IOW things that are
known broken and nobody steps up to fix them.
Again, I'm all ears for better suggestions on how to document in OE
build-time dependencies and failures so that ideally "bitbake $target"
will always work or say "no suitable provider found". What I've heard
so far is not a solution.
Regards
Rolf
next prev parent reply other threads:[~2009-05-21 23:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-21 20:20 [RFC] policy about nonworking recipes Rolf Leggewie
2009-05-21 20:41 ` Koen Kooi
2009-05-21 21:05 ` Philip Balister
2009-05-21 21:12 ` Christopher Larson
2009-05-21 21:36 ` Rolf Leggewie
2009-05-21 21:12 ` Rolf Leggewie
2009-05-21 21:46 ` Koen Kooi
2009-05-21 21:53 ` Philip Balister
2009-05-21 22:59 ` Rolf Leggewie [this message]
2009-05-21 23:29 ` Philip Balister
2009-05-21 23:46 ` Rolf Leggewie
2009-05-22 7:57 ` Yuri Bushmelev
2009-05-21 21:16 ` Rolf Leggewie
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='gv4md5$jmq$1@ger.gmane.org' \
--to=no2spam@nospam.arcornews.de \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@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.