[RFC] policy about nonworking recipes

[RFC] policy about nonworking recipes

[Rolf Leggewie]

Hi,

we have recipes/nonworking/ to collect known-to-be-broken recipes.  With 
the explosion of MACHINE, DISTRO and other settings, most all recipes 
are prone to fail in some circumstances.  Occasionally, this has led to 
packages being moved to nonworking that were only broken for some 
occasions and possibly essential for others.  Problems reported in the 
bug tracker had not always gotten on the radar of the person needing the 
recipe.  The result is frustration left and right.

We already have COMPATIBLE_MACHINE and COMPATIBLE_HOST, but they're not 
commonly used.  As a matter of policy, I think we should agree on 
setting COMPATIBLE_MACHINE to an empty string for packages that fail in 
do_configure or do_compile and which otherwise would have been a 
candidate for recipes/nonworking.  The recipe will then not be 
considered by the parser.

The person who wants the recipe finds it right where he would expect it 
and can add a regexp for the MACHINE he knows this recipes is working 
for.  Furthermore, "git log" can't track moving operations very well and 
this proposal avoids renaming files.

I think that, eventually, "bitbake world" should be working again and 
usable as a test case.  I suggest to use COMPATIBLE_MACHINE because I 
assume that to be the more common issue.

Best regards

Rolf

Re: [RFC] policy about nonworking recipes

[Koen Kooi]

On 21-05-09 22:20, Rolf Leggewie wrote:

> I think that, eventually, "bitbake world" should be working again and
> usable as a test case.

A laudable goal...

> I suggest to use COMPATIBLE_MACHINE because I
> assume that to be the more common issue.

NAK, we have a perfectly good EXCLUDE_FROM_WORLD = "1" for that, which 
is already used in lots (well, 23) recipes and classes.

Re: [RFC] policy about nonworking recipes

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

Koen Kooi wrote:
> On 21-05-09 22:20, Rolf Leggewie wrote:
> 
>> I think that, eventually, "bitbake world" should be working again and
>> usable as a test case.
> 
> A laudable goal...
> 
>> I suggest to use COMPATIBLE_MACHINE because I
>> assume that to be the more common issue.
> 
> NAK, we have a perfectly good EXCLUDE_FROM_WORLD = "1" for that, which 
> is already used in lots (well, 23) recipes and classes.

Good point, after thinking about the COMPATIBLE_MACHINE idea, I was 
thinking it would also need to be paired with COMPATIBLE_DISTRO also. 
Using the existing EXCLUDE_WORLD would be simpler solution in my mind.

I'm still interested in what other people think.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: [RFC] policy about nonworking recipes

[Christopher Larson]

Philip Balister wrote:
> Koen Kooi wrote:
>> On 21-05-09 22:20, Rolf Leggewie wrote:
>>
>>> I think that, eventually, "bitbake world" should be working again and
>>> usable as a test case.
>>
>> A laudable goal...
>>
>>> I suggest to use COMPATIBLE_MACHINE because I
>>> assume that to be the more common issue.
>>
>> NAK, we have a perfectly good EXCLUDE_FROM_WORLD = "1" for that, 
>> which is already used in lots (well, 23) recipes and classes.
>
> Good point, after thinking about the COMPATIBLE_MACHINE idea, I was 
> thinking it would also need to be paired with COMPATIBLE_DISTRO also. 
> Using the existing EXCLUDE_WORLD would be simpler solution in my mind.
>
> I'm still interested in what other people think. 

Sounds like EXCLUDE_FROM_WORLD + DEFAULT_PREFERENCE would be all that's 
necessary to get nonworking-style functionality without moving the 
recipes, indeed.  At least this way we ensure the recipes stay 
*parsable*, which is more than we can say for the current bits :)

-Chris

Re: [RFC] policy about nonworking recipes

[Rolf Leggewie]

Philip Balister wrote:
> thinking it would also need to be paired with COMPATIBLE_DISTRO also. 

COMPATIBLE_DISTRO does not exist as far as I know.  So if needed it 
would have to be added.  I tried to work with what's there.

Not sure if COMPATIBLE_DISTRO should be added and be OE's 
responsibility.  If there frequently is a situation where something 
builds in one distro and not the other then I guess it would be better 
to dig deeper into the choices those distros made which lead to that 
outcome and act on that.

Re: [RFC] policy about nonworking recipes

[Rolf Leggewie]

Hi,

Koen Kooi wrote:
> On 21-05-09 22:20, Rolf Leggewie wrote:
> 
>> I think that, eventually, "bitbake world" should be working again and
>> usable as a test case.
> 
> A laudable goal...

But not the only one.  And essentially not even the main motivation 
behind this.  For lack of a better description I'd say it's "OE should 
just work" instead of "OE has a gazillion recipes to build a 
fantastillion packages"*.

* "but most of them won't build for you and you only find out after 
compiling for 48 hours, sorry"

>> I suggest to use COMPATIBLE_MACHINE because I
>> assume that to be the more common issue.
> 
> NAK, we have a perfectly good EXCLUDE_FROM_WORLD = "1" for that, which 
> is already used in lots (well, 23) recipes and classes.

Any bb in the repo should be buildable or clearly say where it is not 
and exclude itself from any build where it isn't suitable. 
EXCLUDE_FROM_WORLD does not do that, so it's not a solution.

DEFAULT_PREFERENCE -1 would be feasible but that just says "doesn't 
work" whereas COMPATIBLE_MACHINE is more than likely to be a step in the 
right direction (again, assuming most situations where things don't work 
here but work for somebody else will be machine-dependent).  The 
semantics of COMPATIBLE_MACHINE being "no compatible machines known to 
the last committer".  If it turns out to be a host-dependent issue, 
instead, then the next commit should replace the COMPATIBLE_MACHINE line 
with one listing only the COMPATIBLE_HOSTs.

I'm all ears for differing suggestions, but EXCLUDE_FROM_WORLD isn't 
really a solution.

Regards

Rolf

Re: [RFC] policy about nonworking recipes

[Koen Kooi]

On 21-05-09 23:12, Rolf Leggewie wrote:
>  The semantics of COMPATIBLE_MACHINE being "no compatible machines 
known to
> the last committer".

COMPATIBLE_MACHINE has a well defined meaning, which doesn't lend it for 
this kind of pendantry. COMPATIBLE_MACHINE is meant to prevent people 
building a recipe whose packages have no chance of *running* on a 
different machine (kernels being the most obvious examples, hardware 
daemons less so). It has no place in tagging build time brokenness.

> If it turns out to be a host-dependent issue,
> instead, then the next commit should replace the COMPATIBLE_MACHINE line
> with one listing only the COMPATIBLE_HOSTs.

So let's say you want to build pulseaudio, which requires a recent 
autoconf. And your distro locks that down to an ancient version. You get 
a weird error message that doesn't indicate the problem (most likely a 
broken makefile). So you try all machines present in OE and none works 
and then add COMPATIBLE_MACHINE = "", a while after that someone builds 
it for another distro, that does have the correct autoconf version 
(unbeknowst to the user) and replaces it with COMPATIBLE_HOST (which is 
really COMPATIBLE_ARCH, so not for 'host' issues, but target issues).
Anyone looking at the history of the recipe will draw the wrong 
conclusions, since you decided to make it a COMPATIBLE_MACHINE thing, 
instead of using EXCLUDE_FROM_WORLD (which has a meaning to bitbake/OE) 
or BROKEN = 1 (which has no meaning to bitbake/OE, only to OE devs).

But more importantly, a lot of people (and companies) are using OE in 
ways we don't know about, so deleting things, or preventing them being 
parsed is stabbing them in the eye.

If the recipes offend you, you can bbmask them out in local.conf or in 
your distro.conf, but stop making life harder for the rest of us, the 
time needed to undelete or un-COMPATIBLE_MACHINE recipes isn't free. 
Time spent hearing people bitch about deleted recipes isn't free either. 
OE isn't wikipedia were deleting a cool way to boost your streetcred.

And I think that ultimately it's a distro choice which targets should be 
buildable, if a distro says that 'world' isn't supported, so be it.

Re: [RFC] policy about nonworking recipes

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 2837 bytes --]

Koen Kooi wrote:
> On 21-05-09 23:12, Rolf Leggewie wrote:
>>  The semantics of COMPATIBLE_MACHINE being "no compatible machines 
> known to
>> the last committer".
> 
> COMPATIBLE_MACHINE has a well defined meaning, which doesn't lend it for 
> this kind of pendantry. COMPATIBLE_MACHINE is meant to prevent people 
> building a recipe whose packages have no chance of *running* on a 
> different machine (kernels being the most obvious examples, hardware 
> daemons less so). It has no place in tagging build time brokenness.

Heh, I was just writing this same thought. I do think your approach will 
confuse the meaning of COMPATIBLE_MACHINE. I was on the urge of trying 
to say the same thing (and failing) when Koen's email came through.

Koen also raises some good points in the rest of his email.

Philip

> 
>> If it turns out to be a host-dependent issue,
>> instead, then the next commit should replace the COMPATIBLE_MACHINE line
>> with one listing only the COMPATIBLE_HOSTs.
> 
> So let's say you want to build pulseaudio, which requires a recent 
> autoconf. And your distro locks that down to an ancient version. You get 
> a weird error message that doesn't indicate the problem (most likely a 
> broken makefile). So you try all machines present in OE and none works 
> and then add COMPATIBLE_MACHINE = "", a while after that someone builds 
> it for another distro, that does have the correct autoconf version 
> (unbeknowst to the user) and replaces it with COMPATIBLE_HOST (which is 
> really COMPATIBLE_ARCH, so not for 'host' issues, but target issues).
> Anyone looking at the history of the recipe will draw the wrong 
> conclusions, since you decided to make it a COMPATIBLE_MACHINE thing, 
> instead of using EXCLUDE_FROM_WORLD (which has a meaning to bitbake/OE) 
> or BROKEN = 1 (which has no meaning to bitbake/OE, only to OE devs).
> 
> But more importantly, a lot of people (and companies) are using OE in 
> ways we don't know about, so deleting things, or preventing them being 
> parsed is stabbing them in the eye.
> 
> If the recipes offend you, you can bbmask them out in local.conf or in 
> your distro.conf, but stop making life harder for the rest of us, the 
> time needed to undelete or un-COMPATIBLE_MACHINE recipes isn't free. 
> Time spent hearing people bitch about deleted recipes isn't free either. 
> OE isn't wikipedia were deleting a cool way to boost your streetcred.
> 
> And I think that ultimately it's a distro choice which targets should be 
> buildable, if a distro says that 'world' isn't supported, so be it.
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: [RFC] policy about nonworking recipes

[Rolf Leggewie]

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

Re: [RFC] policy about nonworking recipes

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

Rolf Leggewie wrote:
> 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?

Rolf,

Rather than focus your efforts to improve OE by clearly defining what 
builds and what does not, how about trying to identify a problem felt by 
a large number of developers?

For me (and I hope others), the number one problem is keeping a set of 
"useful" images building on Angstrom (you could expand this to include 
other distros). In my mind, having console-image, and some images that 
support UI's (for machine used with screens etc) would be really 
helpful. Beyond this, actually making sure the images work on the target 
hardware would be awesome.

It seems like identifying a set of common machines, distros, and hw and 
making sure we can consistently provide working images would increase 
the developer base of OE. In turn, this would lead to more people able 
to improve the complete set of meta-data. We really need to recruit more 
developers, and the way to do that (I believe) is have more simple stuff 
just work and work well.

Good night all,

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: [RFC] policy about nonworking recipes

[Rolf Leggewie]

Rolf Leggewie wrote:
> s/autoconf/autoconf >= X.Y/

My attempt at indicating that the solution might be to indicate in the 
bb file that autoconf version X.Y or higher is necessary to build the 
package (symbolizing a replace operation on the DEPENDS line of the bb)

Re: [RFC] policy about nonworking recipes

[Yuri Bushmelev]

Hello!

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

Another portion of FreeBSD ports examples :)
I hope it can be useful.

ATM FreeBSD ports have such knobs in similar area:

# FORBIDDEN     - Package build should not be attempted because of
#                 security vulnerabilities.
# IGNORE        - Package build should be skipped entirely (e.g.
#                 because of serious unfixable problems in the build,
#                 because it cannot be manually fetched, etc).  Error
#                 logs will not appear on pointyhat, so this should be
#                 used sparingly.
# BROKEN        - Port is believed to be broken.  Package builds will
#                 still be attempted on the pointyhat package cluster to
#                 test this assumption.
# DEPRECATED    - Port is deprecated to install. Advisory only.
# EXPIRATION_DATE
#               - If DEPRECATED is set, determines a date when
#                 the port is planed to remove. The date format is
#                 ISO 8601 (YYYY-MM-DD).

# Set these if your port only makes sense to certain architectures.
# They are lists containing names for them (e.g., "alpha i386").
# (Defaults: not set.)
#
# ONLY_FOR_ARCHS
#               - Only build ports if ${ARCH} matches one of these.
# NOT_FOR_ARCHS - Only build ports if ${ARCH} doesn't match one of these.
# ONLY_FOR_ARCHS_REASON
# ONLY_FOR_ARCHS_REASON_${ARCH}
#               - Reason why it's only for ${ONLY_FOR_ARCHS}s
# NOT_FOR_ARCHS_REASON
# NOT_FOR_ARCHS_REASON_${ARCH}
#               - Reason why it's not for ${NOT_FOR_ARCHS}s

Typical examples from real life:
IGNORE=           needs at least FreeBSD 5.3-RELEASE
BROKEN=           Does not compile with GCC 4.2
DEPRECATED=       author has abandoned this program
ONLY_FOR_ARCHS=        i386
ONLY_FOR_ARCHS_REASON= Rebuild of i386 package provided by Nominum.

-- 
Yuri Bushmelev

Re: [RFC] policy about nonworking recipes

[Rolf Leggewie]

Rolf Leggewie wrote:
> DEFAULT_PREFERENCE -1 would be feasible

Actually, I guess that would only achieve the desired result when there 
are other versions of the package, so it really is not an option at all.