From: Philip Balister <philip@balister.org>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] policy about nonworking recipes
Date: Thu, 21 May 2009 17:53:20 -0400 [thread overview]
Message-ID: <4A15CD50.3020203@balister.org> (raw)
In-Reply-To: <gv4i2t$90h$1@ger.gmane.org>
[-- 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 --]
next prev parent reply other threads:[~2009-05-21 22:01 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 [this message]
2009-05-21 22:59 ` Rolf Leggewie
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=4A15CD50.3020203@balister.org \
--to=philip@balister.org \
--cc=openembedded-devel@lists.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.