Re: [PATCH v11 0/9] rutabaga_gfx + gfxstream

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

Gurchetan Singh <gurchetansingh@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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]