alsa cleanup: non-optional midi support, cleaner confd

Some more stuff that has happened recently with cleaning up ALSA ebuilds.  We (as in me, mostly) decided to drop support for the optional MIDI support in the alsa-lib and alsa-utils packages.  It originally was implemented as a hack on our end, always caused headaches when disabled, and a whole lot of ebuilds required that it be implemented anyway, so it wasn’t so optional to start with.

With alsa-1.0.20, I ripped out the midi use flag completely, but instead of fixing the reverse dependencies to check for an either/or scenario, instead it was decided to just go back and change all versions of the alsa-lib/utils ebuilds and to force it on, and then drop the check on those using it.  Thanks to Samuli (ssuominen) for fixing all the applications that were using it.

If you run into any ebuilds that are failing to merge because of the dependency, that are in the main portage tree (sorry, I can’t take responsibility for overlays), try syncing your tree again — it’s possible your last one was during the transition.  If you still find one that isn’t working, feel free to file a bug report at bugs.gentoo.org and assign it to [email protected].

Another change that has needed to happen for a while, though not nearly as dramatic, is that I ripped out the really old config options in the alsasound init script: KILLPROC_ON_STOP and UNLOAD_ON_STOP which would kill process using ALSA, and unload its modules, respectively.  Like before, they caused more problems than they solved (both of which, I might suggest, could be implemented in local.stop if you really needed something like that), and I’m glad to say they are gone.

That’s about all the major growing pains for now — that is, I certainly don’t have anything else on my plate for ALSA or its related applications, other than getting 1.0.20 stable and everything previous to that version removed from the tree.

As always, we appreciate any help people would like to give.  There’s still old bugs open, and it’d be good to know if they are solved or not in the latest release.

I realize some of these changes may be minor bumps for users, and if so, I apologize … but Gentoo is always changing goals and directions, and I’m quite glad that we have the flexibility to change things, instead of being stuck with one method.  Part of growth is just shedding the stuff that doesn’t work.