[oe] [RFC] Stop on multiple providers but none explicitly specified

Tom Rini trini at kernel.crashing.org
Thu May 15 20:11:38 UTC 2008


On Thu, May 15, 2008 at 08:51:29PM +0200, Leon Woestenberg wrote:

> 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.
> 
> 1) Besides fixing this in BitBake (by bailing out, my first proposal),
> 2) an alternative solution is to set the preferred provider for the
> toolchain/libc elements to a built..
> a) ..in each distro file
> b) ..globally where we can build the toolchain/libc elements in
> OpenEmbedded for the target.
> 
> I think 2a)  is not the way OpenEmbedded should work. The distro is
> not the authorative component that decides whether we can build a
> toolchain/libc for each target (like Angstrom does now).
> 
> Shouldn't we do (2b), where the distribution can *optionally* override
> the preferred provider if it knows better?

How do we know what's right?  Since in many cases it's glibc OR uclibc
OR external-toolchain, there is no right default there.  If we just bail
out here..
- Distro maintainers know what's right for their distro and lock things
  down (or know the complex table of their correct answers, and lock
  down).
- End users never see this unless the distro isn't up to date, and ping
  the distro maintainer.
- Custom folks get a build that bails out, with a good reason and they
  pick what they know they need here.

-- 
Tom Rini




More information about the Openembedded-devel mailing list