On Mon, 2 Feb 2015 17:14:22 +0100 Ulrich Mueller <[email protected]> wrote:
> >>>>> On Mon, 2 Feb 2015, Alexis Ballier wrote: > > > Ulrich Mueller <[email protected]> wrote: > > >> 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. > > > We already have three possibilities: ffmpeg, libav or none (only for > > some packages but they do exist). > > Right. > > > With the N-1th proposal, it was overseen that USE="-ffmpeg libav" > > should be forbidden by REQUIRED_USE. > > Why? When you have USE="-ffmpeg", the libav flag is a "don't care" > which is ignored. "ffmpeg" controls the feature, "libav" chooses the > implementation. This is very clear from the flags' descriptions and > was also well explained in the (N-1) news item. Would you offer me a beer each time I'll point you at some user doing USE='-ffmpeg libav' because he wants libav only ? :) > > With the N-1th proposal, we had two bits (USE='ffmpeg libav') to > > code 3 states. With the above proposal, we have a kind of unary > > coding: USE=-ffmpeg means 'none', USE=ffmpeg + ffmpeg_impl_$x means > > '$x'. > > Yes, but you would then have 3 bits (i.e. 8 combinations) to code only > 3 possible states. Yes, unary is very inefficient :) My real answer is: I don't know, I'm fine with both, but IMHO we should aim at something natural and straightforward for users. (and if I can get free beer, that's even better :) ) Alexis.
