Michał Górny posted on Mon, 02 Feb 2015 15:06:40 +0100 as excerpted: > FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg > tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will > exactly get used. Much less confusion.
+1 > Thirdly, this opens space for having more than two different > implementations in the future without having to reset the system. +100 =:^) Having to go thru this yet /again/ doesn't sound like fun! > As for the downsides: > > 1. there is a number of non-meaningful flag combinations. > FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be blocked > via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'. > > 2. There is some more work to get ebuilds correct (REQUIRED_USE). > However, this is a minor issue compared to the potential mistakes in > interpretation of USE='ffmpeg' and USE='libav'. ffmpeg-chooser.eclass ?? Seriously, this sounds like a lot of boilerplate that's ultimately headed for a lot of ebuilds. Implement it ONCE in an eclass and have a simple inherit that's easy to do and standardizes all the messages, required_use conditions, etc. Special-cases such as breaks-with-one-of-them could then be per-ebuild handled with a simple declarative syntax. Set ffchooser_broken_impl=X before the inheritance and let the eclass handle it. Alternatively, keep the eclass simple for the handles-both case and let people special-case-code the one-broken case. What's nice about the eclass idea is that implemented correctly it's forward compatible with the additional implementations possibility as well. Just add the Nth implementation once, to the eclass, and all the ebuilds automatically support it. And if a few break, a quick ffchooser_broken_impl=Z before the inherit gets them working again, complete with standardized error messages, etc. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
