>>>>> On Mon, 2 Feb 2015, Michał Górny wrote: > 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.
> Thirdly, this opens space for having more than two different > implementations in the future without having to reset the system. Maybe > this isn't something worth considering but -- as I see it -- the first > big fork starts a precedent, and both current versions suck :). > Fourthly, there's the case of implicity. Right now USE=-libav implies > ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda > weird since it's supposedly the non-default. With this solution, USE=-* > will result in explicit error asking user to select an implementation. > 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'. > What are your thoughts? In a nutshell, you have a binary choice here, namely ffmpeg or libav as implementation, and instead of one USE flag you want to introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible combinations only 2 are valid. So you need a REQUIRED_USE to forbid some combinations. Please spare us of this. Ulrich
pgpIkVFI7ycMJ.pgp
Description: PGP signature
