Being Drizzle a microkernel DBMS it has a number of plugins, it would be of use to be able to select plugins at compile time. Similarly at what gentoo does with other packages with a {alsa,video}_cards or sane_backends. The attached python script use the output from `./configure --help` to create a $IUSE_DRIZZLED_PLUGINS variable, it's not a USE_EXPAND thing but could be easily converted (it even attempt a metadata.xml). Also attached an ebuild that make use of the former. Whit diff to current portage dev-db/drizzle.
Created attachment 214166 [details] extract_plugins.py try to detect plugins from configure --help output
Created attachment 214167 [details] drizzle-2009.12.1251-r1.ebuild
Created attachment 214169 [details] r0 -> r1 patch
Created attachment 214171 [details] example metadata generated, need to be fixed
I'd sincerely rather not make each a separate USE flag… some are already bound to USE flags (pam, memcache, gnutls), which you're filtering out with – IMHO – too much complexity, and others don't have extra dependencies so are effectively not any extra. Sure Gentoo is based on choices, but on the other hand, too much choice just makes stuff messier. Since they are neither requiring new dependencies (with a few exceptions that can be bound to other standard USE flags), nor they are bloating the daemon (they are loadable plugins), I don't really see the reason to break them further apart.
Francesco, thanks for the initiative, but I agree with Diego on this one. Additionally to his explanation why this isnt a good idea, here's one more: There will some dependencies between plugins, i.e. the replication plugin will most probably require the gearman plugin and some plugin to handle ssl. So in the end, the ebuild would need complex use rules which would confuse users and be a hell to maintain. So, for now I'm changing this bug to wontfix.
I'd also point out (if somebody is going to use this as a reference) that you can override ebuild choices via the EXTRA_ECONF variable set specifically for dev-db/drizzle, so there is no real reason to make the interface with user too complex.
After a good night of sleep EXTRA_ECONF seem more reasonable to me too ;)
