© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Interesting:
- On 12.04.4 and 12.04.3, both libegl1 and libgles2 from backports (saucy) are needed for the provider to install cleanly.
- On 12.04,2, only libegl1 from backports (quantal) is needed for the provider to install cleanly.
This is definitely a very subtle problem with package priorities as decided by apt-get. I think this is by the very nature of the enablement stacks; the Ubuntu CDs come with a pre-installed set of packages from one of the stacks, but I didn't find an easy way to "depend on package X from the enablement stack I have installed". I even saw different behaviors depending on whether I recommend or depend on the required packages (recommends usually tries to remove the packages, while depends usually complains about missing dependencies).
I tried something like:
Depends: libgles2-
But even then, it doesn't really choose the appropriate set of packages; this only worked correctly on trusty and 12.04.4 (saucy stack), but fails (wants to remove packages in 12.04.2-quantal, and simply fails due to unmet dependencies on 12.04.3-raring).
As it stands, the only way to solve this reliably is to preinstall both libgles2-mesa and libegl1-mesa from the appropriate enablement stack prior to (or along with, in the same apt-get command) installation of our provider. The problem is that determining the appropriate version of the packages is a bit tricky.
I'll ask on #ubuntu-devel on Monday to see if there's a better way to handle this, and then update accordingly.
If we find no other way, then we can make glmark2-es2 an arch-specific dependency per https:/
Depends: blah, blah, glmark2-es2 [armhf arm64]
this will avoid installing the dependency (and thus sidestep the entire conflict) on non-arm architectures, meaning the test will not run by virtue of its job definition's package requirements.