All of lore.kernel.org
 help / color / mirror / Atom feed
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




  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.