[oe] Adding support for DirectFB across the board

[Mike (mwester)]

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.

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?

Is it really necessary that pango-directfb and pango provide the same thing,
from a "PROVIDES" point-of-view?  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.

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!"?

Thanks,
Mike (mwester)

On 9/24/07, shanevolpe at gmail.com wrote:
> Thanks for the feedback.  I have a couple more questions:
>
> First should I go into all the pango packages and also add
> RCONFLICTS="pango-directfb".  If I should do that can I just and it to
> the pango.inc and override it in pango-directfb with
> RCONFLICTS="pango-directfb"
>
> Second, I have a situation were if you build directfb-1.0 and then
> build directfb-1.1.0 there will be library files for both of them in
> staging.  This is an issue because it seems some packages may use the
> 1.0 libs and others will use the 1.1 libs causing issues on the target
> board which is running 1.1.0.  How should I handle this,  I want to
> completely remove directfb-1.0 from the staging area when directfb-1.1
> is installed.
> Regards,
> Shane
>
>
> On 9/24/07, Koen Kooi <k.kooi at student.utwente.nl> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Richard Purdie schreef:
> > > On Sun, 2007-09-23 at 15:20 -0400, shanevolpe at gmail.com wrote:
> > >> I have been adding in support for directFB to as many packages as
> > >> possible, however one issue I have ran into several times is what do
I
> > >> do when there are packages that can be compiled with X11 or directfb
> > >> support and then what do you do with packages that may depend on a
> > >> package compiled with directfb or X11.  Ok that was pretty confusing,
> > >> let me give an example.
> > >>
> > >> I have added cairo-directfb which compiles cairo with directfb
instead
> > >> of X11.  Next I wanted to add (update) gtk+-directfb to use
> > >> cairo-directfb instead of cairo.  That part was easy I just changed
> > >> the DEPENDS cairo in gtk+-directfb to cairo-directfb..  The issue
came
> > >> when I noticed that gtk+ also requires pango which requires cairo so
> > >> what do I do here, do I make a new pango called pango-directfb?  It
> > >> seems like the better thing would be set up a virtual/cairo and set
it
> > >> to either cairo or cairo-directfb.  If I go that route how do I set
it
> > >> up so it does not break everyone's build that does not have
> > >> virtual/cairo set, is there a way to default it to something like
> > >> cairo?
> > >
> > > The thing you need to consider is that pango compiled with a standard
> > > cairo is a different package to pango compiled with cairo-directfb.
> > >
> > > The virtual namespace is used to show things that are equivalent and
> > > pango is different to pango-directfb since I couldn't interchange
them.
> > >
> > > You therefore need to create a pango-directfb, ugly as that may be
(.inc
> > > files can minimise the ugliness though).
> >
> > Don't forget to add RCONFLICTS statements, since the resulting binary
has the same name (IIRC)
> >
> > regards,
> >
> > Koen