[oe] Adding support for DirectFB across the board

[Paul Sokolovsky]

Hello Mike,

Wednesday, September 26, 2007, 1:02:43 AM, you wrote:

> Another ugly issue has reared its head.  This occurred with the OpenMoko
> build, but will affect most other distros as well.  The problem is that as
> far as bitbake is concerned, there is absolutely no difference between
> pango-directfb-1.18.1 and pango-1.18.1, at least in terms of their ability
> to satisfy dependencies.

> Thus, the simple act of creating pango-directfb-1.18.1.bb was enough for new
> builds to select pango-directfb instead of the pango recipe -- so the same
> build that worked yesterday morning fails in various ways now.  On a
> positive note, at least the problem of incorrect recipe selection is
> discovered at build time that way -- if it built without error it is
> possible that the same build done today will have a radically different
> binary image than one done yesterday, and would go undetected until the
> binary failed.  Note that existing build environments are fine; the
> selection of pango vs pango-directfb has already been done, and bitbake will
> be happy that the dependency on pango is met.

> My first thought was to place my favorite magic incantation (PREFERENCE =
> "-1") in the pango-directfb recipe, but that matters not.  Even such
> powerful magic cannot overcome this problem.

  I faced this issue too and chatted about it with Richard Purdie, but
I believe it isn't even submitted as as bitbake bug. But in general,
this should be the right and the most logic solution - unless
PREFERRED_PROVIDER explicitly selects some variant, one with higher
preference should be used, not random.

> Consulting with the experts on #oe, it seems that the only solution is to
> add "PREFERRED_PROVIDER" lines for every distro that explicitly select which
> recipe they want.   I simply deleted the *-directfb recipes so I could get
> the build running, as time was not on my side -- I had 6 hours of build time
> to catch up on from this problem.

> A few questions, then:

> First, this fails the principle of "least surprise".  How is it that when I
> specify a dependency on "pango" that the "pango.bb" recipe is ignored and
> the "pango-something-different.bb" recipe is used instead?  That's just not
> logical.  Shouldn't bitbake select the one who's name matches exactly, when
> all else is equal?

  Mildly good heuristic too, but using DEFAULT_PREFERENCE would be even
better.

> Is it really necessary that pango-directfb and pango provide the same thing,
> from a "PROVIDES" point-of-view?

  Apparently yes, as they provide the same facility/functionality, but
different implementation of it. It is the essence of PROVIDES. And we
shouldn't give up this idea simply because current version of
OE/bitbake doesn't do it right.

>   A simple change in name would avoid this
> problem completely.  I think we're just asking for confusion, and the
> problems that stem from confusion, by having multiple somethings that claim
> to provide the same thing.

> If it is, in fact, necessary that these two recipes provide the same things,
> then since one is clearly in early development and can destabilize so many
> different distros, then why can we not use a branch to do the initial
> testing and development, with a scheduled merge to the mainline so that the
> distros are all alerted to the need to verify and test when major changes
> happen?   This is a pet peeve of mine - we seem to have frequent "events"
> that result in mass build breakage where the only fix is to have  everyone
> delete their tmp directories, resync, and build from scratch!  As a
> stockholder in Intel, I am grateful for the resulting increased demand for
> quad-core CPUs, but as a developer, each of these surprise events takes a
> full day of productivity away.  I think all of us value the time we spend on
> this hobby, and doing disruptive changes on a branch in isolation just seems
> to me to be a respectful, and decent thing for each developer to do as part
> of being a community member.  JMNSHO.

  With a good chance, that won't improve integral productivity of OE
developers, just will make breakages "more scheduled". At least not
before we'll make tools and conventions right.

> Finally, can we have bitbake be a bit more "in your face" about its
> decisions when there are no external criteria provided?  A warning to say
> "Hey! I've just selected "pango-directfb" to satisfy the dependency for
> "pango" -- but you should know that "pango" would equally-well satisfy the
> dependency, and I picked one only because you didn't provide any hints to
> select one over the other!"?

  That's exactly what it does - it says something like "Consider
defining PREFERRED_PROVIDER". It's notice though, IIRC.

> Thanks,
> Mike (mwester)

[]

-- 
Best regards,
 Paul                            mailto:pmiscml at gmail.com