On Wed, 31 Aug 2016 23:36:21 +1200 Kent Fredric <ken...@gentoo.org> wrote:
> On Wed, 31 Aug 2016 09:43:08 +0200 > Alexis Ballier <aball...@gentoo.org> wrote: > > > nobody is talking about a premature unmask and even less about > > firefox :) > > Right. My bad on the FF :) ( ffmpeg having FF in it is clearly > perturbing my brain ) > > But my point really is that *chromium* has end users desiring > latest-and-greatest for valid security reasons. > > And the strategy of allowing temporary USE masking means the > life-cycles of stabilization between Chromium and ffmpeg don't need > to be tied together. > > That way we're not motivated to push stabilization of ffmpeg into end > users systems in order to satisfy the security cycles of Chromium, so > we can get Chromium stable and secure without necessitating we do the > same with ffmpeg. > > And as stabilizing/unmasking ffmpeg relies mostly on the ability for > its reverse dependencies not to be broken, this essentially means > without the USE mask option, our stabliziation/unmasking workflow for > Chromium is now dependent on everything that uses ffmpeg. > > And I'd just rather we not create such a tight, inflexible dependency > that motivates us to propagate breakage when there's a clear path > that doesn't propagate breakage. For years we've been patching packages to work with >= our latest stable version of ffmpeg/libav and unbundle it. Even mplayer. Chromium shouldnt be any exception. Patching consumer packages that way has some advantages: - Maintainers do not need to wait for ffmpeg to be stabilized. - ffmpeg does not need to be stabilized in lockstep with a few dozen packages that work with this only version. x 2 if you replace 'stabilized' by 'unmasked' in the above. Most often it is rather trivial to do; sometimes really annoying (hey gst)...
