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