All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: openembedded-devel@openembedded.org
Subject: Re: [RFC] Stop on multiple providers but none explicitly	specified
Date: Thu, 15 May 2008 22:45:32 +0100	[thread overview]
Message-ID: <1210887932.7097.107.camel@localhost.localdomain> (raw)
In-Reply-To: <c384c5ea0805151151v35e28a99i2ccb39157d5d47f6@mail.gmail.com>

On Thu, 2008-05-15 at 20:51 +0200, Leon Woestenberg wrote:
> On Thu, May 15, 2008 at 6:42 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> > Bitbake will pick one, the options in brackets are in the order bitbake
> > will choose them. We sort them alphabetically iirc since that is more
> > deterministic than depending on parsing order which was the previous
> > approach.
>
> I agree it's more deterministic seen from the BitBake point-of-view
> and that's an improvement.
> 
> However, is it intuitive from the *user's* point-of-view to have
> BitBake make this decision?
> I think not; at least in the case of OpenEmbedded, there is at least a
> 50% chance this is not what the user intended.

You're making this sound clear cut and its not quite that easy :).
Firstly, 50% isn't a good figure, there is no limit to the number of
different packages which provide a given target so it could be 33%, 25%
or worse.

Secondly, there often is a good default choice its just bitbake doesn't
have the information to make it. For example, we'd probably all agree
that we'd like bitbake to by default:

Use uclibc for linux-uclibc/linux-uclibcgnueabi builds to satisfy virtual/libc
Use glibc for linux/linux-gnueabi builds to satisfy virtual/libc
Use libx11 to satisfy virtual/libx11

I guess what we could do is give each provider a PROVIDER_PREFERENCE =
"0". glibc then does:

PROVIDER_PREFERENCE_virtual/libc_linux = "1"
PROVIDER_PREFERENCE_virtual/libc_linux-gnueabi = "1"

uclibc does:

PROVIDER_PREFERENCE_virtual/libc_linux-uclibc = "1"
PROVIDER_PREFERENCE_virtual/libc_linux-uclibcgnueabi = "1"

libx11 does:

PROVIDER_PREFERENCE_virtual/libx11 = "1"

etc. and then it becomes a case of having bitbake use this information.
It would then be able to error if more that one entry had the highest
preference for a given provider and yet the sane defaults should work.
This should also mean no specific distro setup is needed yet the distro
can set PREFERRED_PROVIDER statements which override the above
PREFERENCES if wanted.

Does that make sense?

Cheers,

Richard




  parent reply	other threads:[~2008-05-16 10:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-14 21:36 [RFC] Stop on multiple providers but none explicitly specified Leon Woestenberg
2008-05-15 16:42 ` Richard Purdie
2008-05-15 18:38   ` Tom Rini
2008-05-15 18:51   ` Leon Woestenberg
2008-05-15 20:11     ` Tom Rini
2008-05-15 20:50       ` Leon Woestenberg
2008-05-15 22:06         ` Tom Rini
2008-05-15 22:25         ` Koen Kooi
2008-05-15 21:45     ` Richard Purdie [this message]
2008-05-16 21:44       ` Leon Woestenberg
2008-05-17 21:59         ` Richard Purdie
2008-05-18 22:48           ` Leon Woestenberg
2008-05-19  8:38             ` Richard Purdie

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=1210887932.7097.107.camel@localhost.localdomain \
    --to=rpurdie@rpsys.net \
    --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.