[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#729203: Packaging for FFmpeg avoiding conflicts with libav



On Sat, Feb 22, 2014 at 11:18 AM, Andreas Cadhalpun
<andreas.cadhalpun@googlemail.com> wrote:
> Hi Antoine,
>
>
> On 22.02.2014 18:56, Antoine Beaupr=E9 wrote:
>>
>> On 2014-02-22 12:39:20, Andreas Cadhalpun wrote:
>>> The ffmpeg package does not provide qt-faststart to avoid a conflict
>>> with libav-tools.
>>
>>
>> Fair enough - there could be a qt-faststart binary package which could
>> conflict with libav-tools.
>
>
> Upstream thinks qt-faststart is not used very often nowadays and there ar=
e
> not many differences between the ffmpeg and the libav version. So anyone =
who
> needs qt-faststart can install libav-tools. I don't see a need for a
> qt-faststart binary package, but if there were bugs in the libav version
> that are not in the ffmpeg version, we could create a qt-faststart packag=
e.

IIRC FFmpeg qt-faststart is faster than Libav because of
http://git.videolan.org/?p=3Dffmpeg.git;a=3Dcommitdiff;h=3Df4d9148fe282879b=
9fcc755767c9c04de9ddbcfa.

>
>
>>> I'm not sure if this package will build on every architecture, because =
I
>>> can't test that.
>>
>>
>> Maybe an upload to experimental could test that? :)
>
>
> I intended to suggest this first, but unfortunately something in
> experimental is broken, which leads to a test failure of ffmpeg, more
> specifically the test acodec-flac fails in experimental.
> It doesn't fail in unstable and testing, so an upload to unstable should =
be
> fine.
> But if it fails to build on some architecture, it will not enter testing,=
 so
> there should be no problem in uploading to unstable.
>
>
>>> I fixed most of the lintian problems, but some remain:
>>>
>>>    * E: debian-watch-file-pubkey-file-is-missing:
>>>         This is a bug in lintian [2].
>>>    * E: embedded-library: I don't understand this one:
>>>         Does it complain about libavfilter embedding libavfilter?
>>>         Seems like a bug in lintian.
>>
>>
>> Not sure about those.
>
>
> Well, the first is a bug in lintian due to the transition from
> debian/upstream-signing-key.pgp to debian/upstream/signing-key.{asc,pgp},
> discussed on debian-devel recently.
> The second is a mystery to me.

Does the libav package has those warnings?

>
>
>>>    * W: manpage-has-errors-from-man:
>>>         I don't know how to fix the manpages. Can someone help?
>>
>>
>> I had the manpage errors as well, I think we can ignore those for now.
>
>
> I figured this as well, but maybe someone knows how to fix it.

That is upstream problem. See e.g. ffmpeg/doc/ffmpeg.texi ll. 805 [1].

>
>
>>> With this package, users can install either ffmpeg or libav-tools and
>>> developers can either depend on lib*-ffmpeg-dev or on lib*-dev and
>>> everyone should be happy.
>>
>>
>> That would be awesome.
>
>
> Exactly my opinion. ;)
> By the way, of course users can also install both ffmpeg and libav-tools =
and
> also packages build against ffmpeg and other packages build against libav=
.

Yay! I didn't think of a way good enough like that.

>
>
>>> Adrian, do you agree that this is sane?
>>>
>>> If the security team is not willing to support both, they can ask the T=
C
>>> to decide which one to use, but this does not prevent an upload of
>>> FFmpeg.
>>
>>
>> I don't see why security would complain: as things stand there are
>> hundreds of security issues that have been fixed in ffmpeg (see the
>> Google audit) which have not been fixed in libav... It seems to me
>> ffmpeg is only more secure than libav at this point...
>
>
> Previously, Moritz M=FChlenhoff from the security team voiced his concern=
s
> about having to apply security fixes for both [1]:
> "But we still try to minimise such cases as much as possible. And for
> libav/ffmpeg this simply isn't managable at all due to the huge stream
> of security issues trickling in. We need definitely need to pick one
> solution only."
>
> I do not share these concerns, as there are e.g. mysql and mariadb happil=
y
> coexisting, but then again, I'm not on the security team.
>
> But should they decide that it will not be possible to support both packa=
ges
> for security updates, your argumentation would clearly favor ffmpeg over
> libav, probably leading to the removal of libav from the archive.
> From my point of view this would be wrong, as I think the users and
> developers should decide for themselves, which package they want to use, =
and
> preventing one from being distributed in Debian only produces a great amo=
unt
> of dissatisfaction and unhappiness among the users and developers.

Thank you so much for all your work!

[1] http://git.videolan.org/?p=3Dffmpeg.git;a=3Dblob;f=3Ddoc/ffmpeg.texi;h=
=3D1244cc4e031a26536f6f3587e50a00114adc8e85;hb=3DHEAD#l805


Reply to: