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

[Andrea Adami]

On Sat, Jan 7, 2012 at 2:42 PM, Martin Jansa <martin.jansa at gmail.com> wrote:
> 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.

Sorry but this is not enough in order to obtain a core-image-sato with
working xserver on first run.
The meta-oe layer is 'toxic' in that regard.

>
>> 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).
>

Those patches ought to be sent upstream long agoi...
I'm sure Florian will apply almost immediately once aware.


>> 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.
>

This is my last reply to this thread.
Again I'm sorry to force maintainers of external layers to react and
make hanges but there is anything wrong with this.
We did agree the policy of meta-oe is the same of oe-core, thus no BSP
code is allowed. Stop.
I'd expect the maintainer agrees.

Cheers

Andrea


> Regards,
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>