[oe] [RFC] policy about nonworking recipes

Rolf Leggewie no2spam at nospam.arcornews.de
Thu May 21 22:59:46 UTC 2009


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





More information about the Openembedded-devel mailing list