Select provider of libav* libraries

[Andreas Cadhalpun]

Hi Jonas,

On 15.05.2015 11:13, Jonas Smedegaard wrote:
> Quoting Reinhard Tartler (2015-05-15 09:23:13)
>> Also, given that Libav supports significantly less codecs and formats 
>> (and in some cases specific variants or features of codecs), many 
>> security issues simply don't apply.
> 
> I find above important, not only for security but for long-term 
> maintenance in general.

Unfortunately that argument is misleading at best, as I explained in my
reply to Reinhard's mail.

> To me the two libraries are like staying-bleeding-edge and conservative 
> flavors of roughly same API.  Some upstreams favor bleeding edge - they 
> are not bound by several-year maintenance commitment like us - but we 
> really should favor the conservative of the two.

As the "conservative" flavor means (security) issues don't get fixed in
a timely manner, I think Debian would be much better of with the "bleeding
edge" flavor.

> Just as Debian generally favors upstream formal releases over snapshots 
> of upstream development: Might be less exciting code, but in the context 
> of Debian "exciting" is a warning sign and "boring" is good!

There are many "exciting" bugs in Libav that are fixed in FFmpeg.

> If we must choose one I favor libav, and I envision a path to gradually 
> make room for both - by treating one as the lesser exciting alternative:
> 
>   * For projects supporting both (either natively or by patching) either 
> link only against the boring one, or do as mpv linking boringly targeted 
> unstable and excitingly targeted experimental - both to aid in _library_ 
> debugging and for those preferring to live on the edge.

Linking against one in unstable and the other in experimental increases
the maintenance burden.

>   * For projects supporting only ffmpeg release only to experimental
>     (for now - see below).

As not many enable the experimental repository, only few would be able
to use these packages.

>> What project is less effort for the security team?
>> - I'd say Libav, the security patches have significantly better commit 
>> messages and descriptions, and generally make much more sense at least 
>> to me. Maybe Moritz can elaborate on this.
> 
> Nowadays the security team has a distinct way of flagging packages as 
> not-security-supported (see e.g. package debian-security-support).
> 
> If we consistently treat the libraries as boring vs. exciting like I 
> propose above, the security team might be convinced to tolerate both in 
> stable - flagging the exciting one and anything linked against it as 
> unsupported by them.

I suggested something like that for jessie, but the reply was that having
no security support means essentially that it's unfit for stable.

Best regards,
Andreas