[oe] Adding support for DirectFB across the board

Tue Sep 25 23:49:01 UTC 2007

Mike,
Thanks for the feedback, I will remove pang-directfb until I figure
out the correct way to add it.  In truth we should NOT need
pango-directfb but the issue is pango has cairo as a dependency (even
though it is NOT needed for build) and cairo must be built with
directfb support so I added cairo-directfb.  I did not want to disturb
an existing package so I created pango-directfb instead of removing
cairo from pango's dependencies.   If I recall correctly there were
some X packages that were in pango's dependencies (also not needed to
build pango) and I did NOT want to remove them either.

I would love more feedback on how I should handle this issue.
Regards,
Shane

On 9/25/07, Mike (mwester) <mwester at dls.net> 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.
>
> 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
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

-- 
Registered Linux User: #293401