[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