[Bf-committers] [BF-committers] Updating FFMPEG

GSR gsr.b3d at infernal-iceberg.com
Sun Aug 9 22:42:30 CEST 2009


Hi,
peter at schlaile.de (2009-08-09 at 1042.28 +0200):
> If I got it correctly, the Debian maintainer had problems keeping up with 
> the latest version / or the version used in Debian.

It is not only about keeping up per se, but every time there is an
problem that needs fixing in lib-whatever, if the programs are static
linked to that lib, it triggers a huge rebuilt followed by huge
downloads. If the fix is for something really serious like security,
the sooner it happens the better. While if the lib is dynamic, those
issues go away: updates are enjoyed by all programs, bandwidth in the
network and memory bus is used more wisely, disk and memory space is
shared, etc. The issue that replaces it is syncing with APIs, sonames,
etc which they are more used to.

Plain old static vs dynamic discussion. Debian maintainer was the one
to make it public, but it affects any other distribution.

> But that will happen to *any* program, that uses ffmpeg, since API changes 
> can happen any time. (And has nothing to do with the fact, that we include 
> a certain version of ffmpeg within our source tree...)

They want to get rid of any static approach (extern/ or lib/), and use
dynamic (system wide library), I thought that was the idea. :-/

So yes, what they want is some changes about usage method (be it
wrappers, more coordinated change of version or whatever) of libraries
and not just moving them around the tree. OTOH, I guess they will be
happy to help pushing patches to ffmpeg or any other lib, to find some
middle ground that makes the global situation easier in the long run.

GSR
 


More information about the Bf-committers mailing list