On Sat, Jan 07, 2012 at 02:22:24PM +0100, Andrea Adami wrote: > On Sat, Jan 7, 2012 at 11:49 AM, Martin Jansa <[email protected]> wrote: > > On Sat, Jan 07, 2012 at 08:41:51AM -0200, Otavio Salvador wrote: > >> On Sat, Jan 7, 2012 at 06:05, Koen Kooi <[email protected]> wrote: > >> > >> > -----BEGIN PGP SIGNED MESSAGE----- > >> > Hash: SHA1 > >> > > >> > Op 07-01-12 00:55, Andrea Adami schreef: > >> > > * delete patches meant for BSP layers * bump PR > >> > > >> > With a recipe like xserver-common I don't see a point in going all out > >> > BSP > >> > on it. This patch just moves things to layers just for the sake of moving > >> > it > >> > to layers. I strongly suspect that applying this patch will be a net > >> > burden > >> > on device maintainers instead of a gain. > >> > > >> > >> I agree this is going to be bad at first but those kind of improvements > >> always cause some problems for a later gain. Dropping things that ought to > >> be in BSP layers is a good thing but only after the "fix other layers" time > >> window. > >> > >> I think this is worth it however it might be better to instead port the > >> needed changes to OE-Core and ask other layers to adopt x11-common allowing > >> us to remove this later on. This makes the change easier and avoid some > >> problems for users IMO. > > > > This whole recipe has machine specific bits and removing those bits > > only of some machines (in this case all from meta-smartphone BSPs) > > doesn't improve that recipe. > > > > So if you want to improve it, merge extra functionality (like > > xinput-pointercal) to oe-core and drop this completely, but breaking > > some machines doesn't make thinks better. > > > > Instead of "fixing" it in meta-smartphone BSPs I would just copy whole > > xserver-common back to meta-shr, because I don't have time now to fix it > > properly and spending time on .bbappends is not worth it in this case. > > > > Cheers, > > > > JaMa, from daywork..ffs > > > > _______________________________________________ > > Openembedded-devel mailing list > > [email protected] > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > > > I try to explain again my intent: > > 1) we have at the moment two xserver-nodm-init, one in meta-oe and one > in oe-core > 2) this is intrinsecaly bad and moreover the two recipes are totally > different with regards to runtime dependencies
I'm aware of that and said that many times, just to busy with daywork (in last couple of months) to fix it myself ;/. > 3) as it is now, oe-core expects to use x11-common while in meta-oe > there is xserver-common I've already explained to you to use VIRTUAL_RUNTIME vars. > 4) xserver-common is an old recipe coming from the oe-classic times, > designed to work with gpe environments and targeting mostly kdrive. > Thius recipe contains alot of BSP code. Yes and those patches you've removed are not making it worse, upstream script contains a lot of BSP code already and those patches are just making it more complete (think about it as patch which should be applied upstream not in BSP layer). > 5) today, if one builds core-image-sato distroless for zaurus qvga > using meta-oe the xserver won't start because of the bad settings > provided by the recipe. see A3). > So, I already sent a msg in that regard before ( > http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-October/035564.html > ) and now I'm trying to help cleaning both sides. > The patch for x11-common was taken in oe-core but this one for meta-oe > is unexpectedly under discussion. > BE sure my intentions are not to increase maintenance burden, on the > opposite I'd like neutral/sane defaults and patches to override those > in the BSP layers. burden is to force people to fix recipe which should be removed instead. Regards, -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
