All of lore.kernel.org
 help / color / mirror / Atom feed
From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@openembedded.org
Subject: Re: [RFC] policy about nonworking recipes
Date: Thu, 21 May 2009 23:46:05 +0200	[thread overview]
Message-ID: <gv4i2t$90h$1@ger.gmane.org> (raw)
In-Reply-To: <gv4g4j$2r4$1@ger.gmane.org>

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.




  reply	other threads:[~2009-05-21 21:53 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 [this message]
2009-05-21 21:53       ` Philip Balister
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='gv4i2t$90h$1@ger.gmane.org' \
    --to=k.kooi@student.utwente.nl \
    --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.