Gurchetan Singh <gurchetansi...@chromium.org> writes: > It's harder to get the attention of the Android build team than the Chrome > build team. Though, there are a few issues with AEMU/gfxstream packaging > we also need to figure out -- see "[PATCH v13 0/9] rutabaga_gfx + > gfxstream" for details -- interested in your opinion on the matter!
None of the other points there are issues for me — in Nixpkgs, every package is installed to a unique prefix (different versions of the same package, or even just different build recipes for the same version, or different dependencies result in different prefixes), so library versioning and the /usr/include directories are not blockers. Static libraries are also fine for Nixpkgs — any change to a library, static or dynamic, causes all dependents to be rebuild against the new library, so the only real disadvantage to static libraries is the duplication on disk, which isn't a big deal. All that's to say, I'm ready to have rutabaga support, including gfxstream, in our QEMU package, as soon as a release of QEMU including it is made. Everything Marc-André has identified would still be nice to have fixed, but for us specifically, none of it is a blocker, even the tags I asked for.
signature.asc
Description: PGP signature
