Split hybris stuff out into a separate layer

[casept]

I'm currently trying to port the Gear 2, based on my mainline kernel fork.

With the current project structure, I have to manually remove all the hybris-related patches in my device layer that don't make sense for my watch (e.g. the mesa dependency removal in qtbase, OpenGL removal in SDL2, the addition of pulseaudio-modules-droid to pulseaudio etc. Finding all these spots is a lot of effort and would have to be repeated if any new mainline-based devices were to be introduced in future.

I think the following split might make sense:

meta-asteroid: Recipes for shared components; HAL-neutral
meta-mainline: Recipes and patches for watches running mainline; inert on hybris-based watches
meta-hybris: Recipes and patches for watches running libhybris; inert on mainline-based watches

I'd be willing to the work if this looks OK to you.

[FlorentRevest]

Thank you for opening this and sorry it took me so long to get to it

I'm currently trying to port the Gear 2, based on my mainline kernel fork.

Nice!

With the current project structure, I have to manually remove all the hybris-related patches in my device layer that don't make sense for my watch (e.g. the mesa dependency removal in qtbase, OpenGL removal in SDL2, the addition of pulseaudio-modules-droid to pulseaudio etc. Finding all these spots is a lot of effort and would have to be repeated if any new mainline-based devices were to be introduced in future.

You cite three precise examples, let's have a look:

• the "remove mesa dependency" comment in qtbase https://github.com/AsteroidOS/meta-asteroid/blob/master/recipes-qt/qt5/qtbase_git.bbappend#L4 seems just misleading. it's not actually removing a dependency to mesa but to desktop editions of GL. We use GLES, but libGLES can perfectly well be provided by mesa. That's what we do on QEMU for example. So this should not be a problem for any mainline port (technically, qemu is a "mainline port")
• as for the opengl removal in sdl2 - could you explain more why you think this is a problem ? https://github.com/AsteroidOS/meta-asteroid/blob/master/recipes-graphics/libsdl2/libsdl2_%25.bbappend this just means that the SDL library we build does not support GL but it's only used by third party apps in the community layer anyway https://github.com/search?q=repo%3AAsteroidOS%2Fmeta-asteroid-community%20libsdl2&type=code you're most likely not even building this recipe. If this for some reason really bothers you you can distribute that patch into the hybris port layers and I agree it's technically a little bit of an abstraction leak but in practice it shouldn't have any practical consequences.
• the pulseaudio recipe in meta-asteroid should not have depended on pulseaudio-modules-droid in the first place, this is a mistake. Feel free to remove that dependency https://github.com/AsteroidOS/meta-asteroid/blob/master/recipes-multimedia/pulseaudio/pulseaudio_%25.bbappend#L1 and the second line (the default should be that there is no hybris dep). That requires adding a similar .bbappend to every watch in meta-smartwatch but you'll find plenty of examples of that, for example the way we add dependencies to the qt5-qpa-hwcomposer-plugin package in lipstick on a per-watch basis https://github.com/AsteroidOS/meta-smartwatch/blob/master/meta-bass/recipes-nemomobile/lipstick/lipstick_git.bbappend it's gonna be a bunch of copy pastes, it's not much fun but that's the best we've got so far. Maybe there's a way to factorize those bbappends using a yocto "machine feature" or something and it would be a welcome refactoring, but we just never looked into this ;)

I think the following split might make sense:

meta-asteroid: Recipes for shared components; HAL-neutral

This is indeed what it is supposed to be. The layer might contain recipes which are useful for HAL stuff, (like pulseaudio-modules-droid, it's perfectly fine to have it there) but it should not build anything hybris by default. All layers for hybris ports should have bbappends to enable hybris things conditionally.

meta-mainline: Recipes and patches for watches running mainline; inert on hybris-based watches
meta-hybris: Recipes and patches for watches running libhybris; inert on mainline-based watches

We have meta-smartwatch and it contains a directory per watch. But there can be two MACHINEs for a given watch. For example meta-sparrow defines sparrow and sparrow-mainline. The hybris stuff are only built when building the sparrow (hybris port) MACHINE. When building sparrow-mainline almost nothing changes. AsteroidOS/meta-smartwatch@dff36f6 Notice also the last paragraph of that commit description which points out that pulseaudio shouldn't have had dependencies to pulseaudio-modules-droid by default, but fixing this was left as an exercise for the reader. ;)

[casept]

Thank you for the feedback!

This was posted before we had our discussion on how to approach this properly, I just forgot to close the issue afterwards.

Making the remaining accidental hybris dependencies in the manner we discussed in the Matrix channel is nearly finished now, with the changes living in https://github.com/casept/meta-asteroid/tree/optional-hybris. I need to track down why asteroid-launcher segfaults with them applied on my catfish, then I'll submit a PR.