[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Reinhard Tartler]

Aurelien Jacobs <aurel at gnuage.org> writes:

> Reimar D?ffinger wrote:
>
>> On Mon, Jan 26, 2009 at 09:52:19PM +0100, Reinhard Tartler wrote:
>> > Now something interesting happens: with the new ffmpeg snapshot
>> > libavutil is updated as well. It features a function rename
>> > (ff_gcd->av_gcd), which is according to the ffmpeg development policy
>> > OK, since it is a pure private function. However this rename breaks the
>> > libavcodec51 package horribly. [3]
>> 
>> Hm, can't libavcodec be linked to always use/prefer the libavutil version it
>> was linked to originally?

This is indeed an idea I had yesterday and tried to discuss it on
IRC. In order to implement that idea libavutil could be linked
statically to libavcodec.so.52/libavformat.so.52.

In the short term, we now have to introduce overly strict dependencies
that prevent libavcodec51 to be installed with the new version of
libavutil. This prevents the bugs I quoted yesterday, but makes updating
ffmpeg very painful!

>> Then bumping the minor version on such renames would reduce the
>> issue...

Both major and minor version bumps wouldn't be an issue then at all.

However M?ns was strictly against this idea. I can only suspect why...

Diego, how do you think about the idea of linking libavutil statically
into libavformat.so/libavcodec.so?

>> > In the end this means that libavutil49 must not be renamed until *all*
>> > applications linking against any library of ffmpeg has been recompiled.
>> 
>> I don't understand what you mean by "libavutil49 must not be renamed"...

I'm sorry, I wasn't clear on this point. I should have written "updated"
instead of "renamed", but that wouldn't be too accurate as well.

on updates to a library libfoo, a maintainer has to decide the following
cases:

 a) the library has only internal change, nothing changes externally
 b) the library has additions only, a minor bump is made
 c) the library features changed symbols and/or types, a major bump
    needs to be made

For b), this is noted in the package, so that programs get a correct
versioned dependency generated.

only c) requires a SONAME bump. In that case we introduce a new binary
package so that both the older and the new version of the library can be
installed.

Being able to install both versions of libfoo is critical for having a
smooth transition not requiring all maintainers of all all affected
packages synchronising uploads with each others. This is a real problem!

>> Overall I wonder if it wasn't a really bad idea to give each libav*
>> library a different version number, or at least not bumping major
>> versions together, because it seems to me that is what
>> causes the issue in the end...
>
> This is indeed the root of the problem.
> We have separate version numbers for each libav*, which makes people think
> that the libs are more or less independent from each other, while on the
> same time we never supported linking libav* to another libav coming from
> a different svn revision.

That's what I figured out the hard way. BTW, Michael, this is why I
didn't propose a "compatibility" patch Aurelien posted last night. M?ns
explained me on IRC that ffmpeg distinguishes between internal and
external API and later then that he considers packaging libavutil
separately from libavformat and libavcodec was a bad idea in the first
place.

However if this is the case, why not combining then all of libav* into a
aggregate library libffmpeg.so?

> It is not that uncommon for a distro to support several major version of
> the same lib at the same time. And distro generally don't support several
> version of the same lib with the same major version.
> So to make it clear, distro want to support simultaneously lavc51 and
> lavc52, but they can't handle 2 version of lavu49 at the same time.
> Right now, this is impossible.

That is accurate. Thanks for phrasing it like this!

> I can imagine several solution to this.
> One clean solution would be to never use any internal API of libav_x
> from libav_y. Linking between the various libav* would strictly stick
> to public API.

Yes, that would be ideal for packagers. All libav* could then be
versioned properly. If this was a general policy, a linker script could
be developed which hides all internal API. This way
libavcodec/libavformat and all external applications would be *forced*
to use the public API.

> This would certainly imply exposing more things to public API of
> libavutil. But that way, any change in lavu which would break
> compatibility with old lavc, would also be a public API change, and
> thus, would require major version bump.
> I'm pretty sure this would solve the kind of problem reported here.

In the end I think this would make libavutil much more useful for
external projects!

Another solution/workaround is outlined further above in this email.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4