Hi Anjan,

Thanks for diving into this. I mentioned some ideas on IRC, but I thought I'd put them down here. Just take them with grains of salt. I think we have two issues with the motivation:

(A) We have some "optional" bits of sxmo-utils that should be split out: vvm (maybe even mms?), bluetooth, userscripts (youtube-dl, etc.), maybe even our core locking mechanism. Heck, maybe even modemmanager itself (on devices without a modem). For this, I think it makes sense to have in our Makefile various options (make all; make core; make vvmd) or even split these out into separate git repositories, and in the package manager for the distro have an sxmo-vvm, sxmo-bluetooth, sxmo-etc. I'm in favor of this, since it wouldn't introduce more code, it would just introduce more places where our code is stored.

(B) Some devices will require exceptions to our defaults regardless of what we do with (A). For instance, #2 in your list. And also the pinenote only has one button and no leds, so it requires exceptions. This is a harder issue. On the one hand, the fact that SDM845 doesn't work with pipewire is more of a problem with SDM845 and not a problem for us. I take it we've been kind of waiting to see if this gets fixed "upstream" before changing anything. I'm not sure of the solution. For the pinenote, we did this with our hooks, so maybe something like that for SDM could work... Perhaps we have an sxmo-pipewire and sxmo-pulseaudio-only package? But then how to get the package manager to install sxmo-pipewire vs. sxmo-pulseaudio-only package?

I'm hesitant to try to do something inhouse since it'd be more support and more code for us to handle (like having an sxmo_manage_packages.sh or something). I'd rather figure out a way to get the package manager of the distros to deal with managing which bits of sxmo are installed and which are not.

Anyway, just some thoughts.

I agree we should be careful not to end up with feature creep. What I'm interested in working towards is a menu system to help with managing the different components (point A above). I would prefer to add special cases for each of different motivating factors and combine them later if it they fit well together.

For splitting packages my current plan (although I haven't started working on it yet) is to add a check in sxmo_migrate.sh for packages that have been split from sxmo-utils, aren't installed, and the user hasn't been prompted about before. I think it can be done with just the package name, the sxmo version it was introduced in, and a description of the package. I expect this data, and probably some of the logic, could be repurposed to create a "sxmo modules" menu in the future.

Another option for splitting packages would be add the split packages to the dependencies of the common sxmo metapackage, fork a sxmo-minimal metapackage from it that doesn't have them, and use sxmo-minimal in new images. The issue with this is it would require a new metapackage for each release that splits new packages.

I discussed the SDM845/pipewire problem with briefly with anjan on irc, I think it would be fine to add a special case in the start hook since it's an unusual case, but anjan has a better handle on what that needs than I do.