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 _______________________________________________ pkg-multimedia-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
