libqt4-dev install pulls libegl1-mesa/libgles2-mesa, causing removal of libegl1-sgx-omap4/libgles2-sgx-omap4

[Fathi Boudra]

 Get images to reproduce:
$ wget http://snapshots.linaro.org/11.05-daily/linaro-ubuntu-desktop/20110824/1/images/tar/linaro-n-ubuntu-desktop-tar-20110824-1.tar.gz http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/lt-panda-x11-base-natty/20110824/1/images/hwpack/hwpack_linaro-lt-panda-x11-base_20110824-1_armel_supported.tar.gz
$ sudo linaro-media-create --mmc /dev/mmcblk0 --dev panda --hwpack hwpack_linaro-lt-panda-x11-base_20110824-1_armel_supported.tar.gz --binary linaro-n-ubuntu-desktop-tar-20110824-1.tar.gz

 On the Panda board:
# apt-get install libqt4-dev

libqt4-dev pulls libegl1-mesa-dev/libgles2-mesa-dev, causing libegl1-sgx-omap4/libgles2-sgx-omap4 removal.

libqtgui4 depends on libegl1-mesa.
libqt4-opengl depends on libgles2-mesa/libegl1-mesa.

Package: libegl1-sgx-omap4
Replaces: libegl1-x11
Provides: libegl1-x11
Conflicts: libegl1-x11

Package: libgles2-sgx-omap4
Replaces: libgles2
Provides: libgles2
Conflicts: libgles2

A user expects to install libqt4-dev transparently, using SGX packages that provides EGL/ GL ES2 libraries.

Workaround:
$ sudo apt-get-install libqt4-dev
$ sudo apt-get install libegl1-sgx-omap4 libgles2-sgx-omap4

[seraphym (seraphym)]

Uh, could you please advise on the workaround, because when I do
$ sudo apt-get install libegl1-sgx-omap4 libgles2-sgx-omap4
it removes libgles2-mesa-dev and that removes libqt4-opengl-dev which means I can't build projects with QT & QGLWidget class? am I doing something wrong, or is this workaround only means you can build non QGLWidget projects?

Also could you please up the priority, this really is a bummer :(

[Marko Pellikka (eemapel)]

Yes, this is a real annoyance. The only work-around I know is to build while having mesa stuff installed, and then install omap4 packages back and then run application. But assuming you want to change something and build again, you need mesa packages again, frustrating..

[seraphym (seraphym)]

that's what I was doing but after couple of reinstalls of packages got sick of it and switch to another task. Hope this issue gets resolved fast :(

[Fathi Boudra (fboudra)]

Re-assign to me. There's already enough work on Ricardo's plate.

[Ricardo Salveti (rsalveti)]

On Wed, Sep 28, 2011 at 9:50 AM, Fathi Boudra <email address hidden> wrote:
> Re-assign to me. There's already enough work  on Ricardo's plate.

Thanks, did you check if this is still and issue with oneiric?

[Jiandong Zheng (ezjd)]

I tried and still see such pkg conflict.

After looking into related pkgs, found followings:
1) libqt4-dev only recommends libqt4-opengl-dev so that this shouldn't cause issue if installing w/o recommendation.

2) However, install libqt4-opengl-dev will face same issue because it depends on libgles2-dev while it is a virtual pkg provided by libgles2-sgx-omap4-dev and can't be installed automatically for some reasons.

3) Easier workaround is to install libgles2-sgx-omap4-dev manually, in linaro image. However, I suspect the dependence information from Linaro pkgs has issues regarding this though I can't figure out due to limited deb pkg experience.

[Jiandong Zheng (ezjd)]

Another issue found with libgles2-sgx-omap4-dev as it lack of KHR/khrplatform.h, which will lead to build error when, for example, I built kdelibs with it.

The walkaround is to install libegl1-sgx-omap4-dev as well. However, as I view libgles to be dependence of libegl, I'd like to see this header file to be included in libgles2-sgx-omap4-dev instead.

[Fathi Boudra (fboudra)]

On 26 November 2011 22:38, Jiandong Zheng wrote:
> Another issue found with libgles2-sgx-omap4-dev as it lack of
> KHR/khrplatform.h, which will lead to build error when, for example, I
> built kdelibs with it.

please, fill a separate issue. thanks.

> The walkaround is to install libegl1-sgx-omap4-dev as well. However, as
> I view libgles to be dependence of libegl, I'd like to see this header
> file to be included in libgles2-sgx-omap4-dev instead.

[Jiandong Zheng (ezjd)]

> please, fill a separate issue. thanks.

Bug #897429 created.

[Ricardo Salveti (rsalveti)]

Fathi, any update on this one?

[Jiandong Zheng (ezjd)]

Still seeing this issue when installing kdelibs5-dev. The workaround I did still works too.

libqt4-opengl-dev will pull in libgles2-dev, a virtual pkg provided by both libgles2-mesa-dev and libgles2-sgx-omap4-dev.

Package: libgles2
State: not a real package
Provided by: libgles2-mesa, libgles2-sgx-omap4

I suspect when system always tries to install libgles2-mesa instead of the other to solve the dependencies. According to http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.html (section 7.8), update-alternatives might be the solution, but couldn't figure out how.

[Ricardo Salveti (rsalveti)]

The problem is that with current solution, even with the generic packages working with replaces, mesa will always have the preference by dpkg (as it's the first package at 'or' list).

The workaround I'd also suggest for you is to install the -dev packages from SGX, so it can replace the mesa one, making the applications to also use the SGX -dev packages.

For the ideal solution, guess the way to go would be changing for update-alternatives, but that would require changes at mesa and also the sgx library (not that trivial).

[Marko Pellikka (eemapel)]

I haven't got a chance to test this, but qt-x11 (4:4.7.4-1ubuntu1 and 4:4.8.0-1ubuntu1~ppa1) have some dependency fixes for opengl and qt dev packages. If anyone could check if the work-around is still required on latest images?

[Ricardo Salveti (rsalveti)]

This will get fixed right when we change officially to Precise (during 12.04), as I'll be replacing the current sgx driver with the one using update-alternatives (https://launchpad.net/~rsalveti/+archive/pvr-sgx-omap4).

With update-alternatives the main -dev package will be provided by the mesa packages, and you'll be able to install both at the same time.

[Ricardo Salveti (rsalveti)]

With the precise based rootfs this is not an issue any more, as the pvr driver is now using update-alternatives.