Hi, This was interesting discussion and certainly achieved the goal of soliciting comments... A less aggressive plan:
Rule 1. Unambiguous package naming I won't repeat this, everyone agreed this was sane. I've a patch for mesa that I'll submit shortly. Rule 2. No whitelisting for GL driver conflicts The target GL shall be staged, and situations which result in multiple GLs being installed should handle this case and resolve it. For atom-pc this means building Mesa. For Beagle this means staging the Beagle binary drivers. For Tegra as I've discovered this is "interesting" as they don't appear to provide any headers in their Tegra For Linux tarball... For Cedar Trail and EMGD, the easiest solution is a dedicated Mesa building just GL. As Mesa's DRI driver API isn't stable this is practically required anyway: the ABI of the libGL we build and the libGL that the binary driver was built against need to match. This mesa-just-gl (mesa-solo?) can be in meta-intel unless other machines turn out to have a similar (crazy) requirement. Rule 3. No dependencies on specific GL implementations Useful so that GL implementations are swappable on systems where that can happen, but not essential if there isn't a single blessed GL for sysroot. We'll do this later. Some things that will also happen whilst I do this: 1) mesa-dri renamed to mesa. Let's get this done nice and early! 2) mesa stops architecture-overriding enabling of EGL and GLES, so all architectures that build Mesa get GL/EGL/GLESv1/GLESv2. If you don't want this don't build Mesa, and the namespaced packaging means there won't be conflicts. Any more comments? Ross _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core