[meta-intel] [PATCH 1/1] Revert "emgd-driver-bin: add xorg-abi-video- dependency"

[Tom Zanussi]

On Mon, 2012-12-03 at 11:14 +0000, Burton, Ross wrote:
> On 2 December 2012 23:19,  <tom.zanussi at intel.com> wrote:
> > There's no explanation of what the actual problem was that this commit
> > fixes - likely it was in response to the packaging problems causing
> > YOCTO #3501 and YOCTO #3502.  In any case, nothing should cause a
> > regression like this since xserver-xorg is pinned at 1.9.3 and its
> > contents shouldn't change to cause something like 'xorg-abi-video' to
> > disappear.
> 
> There was a thread on oe-core and the relevant oe-core commits had
> plenty of explanation:
> 
> commit bc41dfb9cd2d3b90d97fa051c90d2f53bacde059
> Author: Ross Burton <ross.burton at intel.com>
> Date:   Mon Oct 22 10:37:24 2012 +0100
> 
>     xserver-xorg: add runtime provides for the driver ABI version
> 
>     The xserver driver ABIs can and do change in a way that is unrelated to the
>     version of xserver, so it's entirely possible to build an image that has a
>     mismatch between the server ABI version and the version that the
> drivers were
>     built against.  xserver detects this and refuses to load the modules.
> 
>     By adding RPROVIDEs to the xserver package that describe the ABI
> versions it has
>     (such as xorg-abi-video-13, xorg-abi-input-11), drivers can RDEPEND on the
>     version that they were built against.  This means that when the ABIs change,
>     there will be package dependency errors at image time instead of images that
>     build fine but don't work.
> 
>     (From OE-Core rev: 8ef5f205aec04140198d5ba0f5c405ae6e977dbe)
> 
> You may have pinned xserver-xorg in the bitbake to 1.9.3 but:
> 
> 1) it's entirely possible for the package feed to get 1.13 from
> another MACHINE, because they'll both be in the "core2" arch feed
> 2) it's enforcing the ABI relationship which can't be expressed in any other way
> 

OK, yeah, I haven't necessarily been following all the threads on
oe-core, just trying to figure out what to pull in or not, and trying to
find something that works here to get past the core-lsb build problem,
which the revert does, but clearly that's not the right answer.

I was looking more for an actual problem you'd run into that the commit
fixed, but it's not important - just ignore this revert, I won't be
applying it.

> > Also there doesn't appear to any xorg-abi-video-8, so it's doubtful
> > that this commit actually fixed the problem it was trying to fix -
> > should it instead be xorg-video-abi-8 which does exist?
> 
> Really?
> 
> ross at melchett /data/poky-master/tmp/work/core2-poky-linux/xserver-xorg/1_1.9.3-r2/deploy-ipks/core2
> $ dpkg -I xserver-xorg_1.9.3-r2_core2.ipk
> ...
>  Provides: xorg-abi-video-8, xorg-abi-input-11
> 
> Where are you seeing xorg-video-abi-8?  I'm concerned that the RPM
> backend is messing things up.
> 

I could have sworn I had, but looking again now, I obviously must have
grepped the wrong thing or something.  Sorry for the false alarm, and
again please ignore this patch..

Tom

> Ross