[oe] [meta-oe] [PATCH] xserver-common: remove extraneous BSP customizations

[Martin Jansa]

On Sat, Jan 07, 2012 at 02:22:24PM +0100, Andrea Adami wrote:
> On Sat, Jan 7, 2012 at 11:49 AM, Martin Jansa <martin.jansa at gmail.com> wrote:
> > On Sat, Jan 07, 2012 at 08:41:51AM -0200, Otavio Salvador wrote:
> >> On Sat, Jan 7, 2012 at 06:05, Koen Kooi <koen at dominion.thruhere.net> 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
> > Openembedded-devel at lists.openembedded.org
> > 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: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20120107/2cf7a475/attachment-0002.sig>