On 2014-11-28 3:48 PM, Ylinen, Mikko wrote: > On Wed, Nov 26, 2014 at 8:01 AM, Damian Hobson-Garcia <[email protected]> > wrote: > >> Hi Mikko, >> >> On 2014-11-26 2:01 PM, Ylinen, Mikko wrote: >>> Hi, >>> >>> On Wed, Nov 26, 2014 at 4:52 AM, Damian Hobson-Garcia < >> [email protected]> >>> wrote: >>> >>>> Hi Mikko, >>>> >>>> On 2014-10-23 12:31 PM, Damian Hobson-Garcia wrote: >>>> >>>> I am proposing: >>>> >>>> Prefer: mesa-libGLESv2 >>>> Prefer: libwayland-egl >>>> Prefer: libgbm >>>> Prefer: mesa-libEGL >>>> >>>> %if "%_repository" == "emulator" >>>> Prefer: mesa-libGL >>>> Prefer: emulator-yagl >>>> ... >>>> %endif >>>> >>>> >>> Would you be able to explain why this is needed. >> Sure. Let me recap/restate a bit since this thread is already a little >> old. >> >> The main goal is to be able to have the ARM versions (I'm working on >> the Renesas versions) of these packages exist alongside the Mesa >> versions (and other ARM versions) without having to create new build >> configurations (and repositories) for each ARM platform. For the purpose >> of this discussion, I will call a package that has multiple versions a >> "multi-versioned package". >> >> Having multiple packages that provide the same files (in the OpenGL/ES >> case, each version will naturally provide its own libGLESv2.so* files) >> will break the rpm build, since the tools will not know which version to >> install when building other packages that require the multi-versioned >> package (for OpenGL/ES, that's most of the graphics libraries). The >> "BuildRequires:" fields in the spec file typically only specify the >> -devel version of the packages via the pkgconfg(), so if only one >> version of each multi-versioned package supplies the -devel package, the >> problem is solved for packages the directly require the multi-versioned >> package. The assumption is that the -devel package contents (.pc file >> and/or headers) should be the same for each version, since they >> essentially do the same thing and should be binary compatible. >> >> During the build process, if package A depends on package B that depends >> on a multi-versioned package C, package B will typically depend on the >> versioned library in packages C instead of the development one (in the >> OpenGL/ES case, it will depend on libGLESv2.so.2.0.0 instead of >> libGLESv2.so). This means that once again there will be a choice as to >> which version of package C should be installed for the build. This >> conflict can be resolved with the "Prefer:" statements in the build >> configuration. >> >> The specific reason for my proposal is that I would like to start the >> process of merging the Renesas versions of these OpenGL/ES libraries >> into the repository, and of course I do not want to break the build. >> >> For the Renesas R-Car M2 platform there are platform specific versions >> of the libgbm, and libEGL libraries. libwayland-egl and mesa-libGLESv2 >> are strictly not necessary, but the 4 together form a good set of what >> could potentially be useful for other platforms and the extra "Prefer:"s >> should hurt anything even if there is only one version of that library >> available. >> > > There are still two things I'm not sure how it'll work: > > 1. mesa provides libgbm. How would OBS know whether it needs to Prefer mesa > libgbm or Renesas libgbm? > 2. how do you ensure Renesas libEGL a) provides the same so version and b) > that specific > RPM gets installed in the image instead of mesa-libEGL > > -- Mikko > 1. The main assumption here is that the different versions of the library must be binary compatible, with different implementation of a common API. In this case libraries linked with one version at compile time should work seamlessly with the other version at runtime. This means that it doesn't matter which version the OBS prefers, and so it should be fine to *always* prefer the mesa version, even on Renesas builds.
2.a) It would be up to the package maintainer of the Renesas version to keep the so versions in sync with mesa. Since a change in version could also indicate a change in the API, it's a good idea to check this to maintain the binary compatibility anyway. (Though the versions have never changed so far). 2.b) Since the mesa version and the Renesas version will have different package names, explicitly putting the Renesas version in the ks file should ensure that the correct version gets picked up. On the other hand, this also means that the builds that want to use the mesa version must also specify that it their ks files, which they currently do not. Thanks, Damian _______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
