[meego-commits] 6181: Changes to Trunk:Testing/mesa

[Anas Nashif]

rpmlint errors can be excluded on false positives using an <pkg>-rpmlintrc files with the rules to ignore. Look for example at the automake package.

Anas



On 2010-08-02, at 8:31 AM, Carsten Munk wrote:

> 2010/8/2 Zhu, Peter J <peter.j.zhu at intel.com>:
>> Two new empty packages?
>> 
>> Peter
> 
> The problem/situation (discussed with me, Fathi, Peng and Kaitlin) is
> that packaging policy / rpmlint declines non-devel packages with *.so
> in them. The problem is that on all GLESv2 and EGL implementations on
> ARM, the default name for libEGL and libGLESv2 is libEGL.so and
> libGLESv2.so (this is mandated by Khronos actually). Not libEGL.so.1
> and libGLESv2.so.2 as forced by packaging policy.
> 
> We're trying to remedy the situation of a binary application
> incompatibility between MeeGo ARM and Harmattan for applications. I
> believe it's the idea for same binary using Qt to work on both.
> 
> The problem exhibits in when we take a binary compiled against
> QtOpenGL on Fremantle or Harmattan:
> 
> Let me illustrate this problem with mcompositor from Harmattan. This
> is an application, using QtOpenGL and GLESv2 APIs - a fairly normal
> usage. A quick 'strings' of the binary shows that this binary depends
> on /usr/lib/libGLESv2.so due to the fact it uses symbols from there.
> 
> If we were to try to run this binary on MeeGo/ARM, we would get a
> linking error. /usr/lib/libGLESv2.so only exists in
> mesa-libGLESv2-devel (which is not suitable on a device).
> 
> I'm taking same binary from Kaitlins EGL experiments, built against
> Trunk:Testing. A quick strings of the binary shows the binary depends
> on libGLESv2.so.2
> 
> If I was to try this binary on Harmattan, I would get a linking error,
> /usr/lib/libGLESv2.so.2 does not exist on Harmattan.
> 
> In MeeGo ARM, right now in libgles2-qemu (getting obsoleted by
> mesa-libEGL/mesa-libGLESv2), I'm breaking packaging guidelines by
> having /usr/lib/libGLESv2.so in a non-devel package in order to be
> compatible with the rest of the world (Check any given GLES
> implementation: SGX, Samsung, MBX, etc..) and our current path with
> Mesa would cause binary incompatibility.
> 
> I've suggested providing a -compat package (adding an ignore to
> rpmlint rule), which
> provides a symlink /usr/lib/libGLESv2.so -> /usr/lib/libGLESv2.so.2 and symlink
> /usr/lib/libEGL.so -> /usr/lib/libGLESv2.so.2. And having that package
> Provides: libGLESv2.so libEGL.so.
> 
> Is this a better solution?
> 
> This means binary applications from Harmattan using EGL/GLESv2 will
> work on MeeGo. Situation needs to be fixed in Harmattan too as no
> libGLESv2.so.2 exists there in order to make MeeGo applications work
> there.
> 
> Best regards,
> Carsten Munk
> _______________________________________________
> Meego-commits mailing list
> Meego-commits at meego.com
> http://lists.meego.com/listinfo/meego-commits