[FFmpeg-devel] Upgrade Trouble

Michael Niedermayer michaelni
Mon Dec 7 14:39:32 CET 2009


On Mon, Dec 07, 2009 at 12:23:14AM +0200, Uoti Urpala wrote:
> On Sun, 2009-12-06 at 20:03 +0100, Michael Niedermayer wrote:
> > On Sun, Dec 06, 2009 at 11:50:21AM +0200, Uoti Urpala wrote:
[...]
> > > Symbol versioning _will_ be needed
> > > for lavc/lavf too at latest at the next version bump (as there are other
> > > libraries depending on them),
> > 
> > maybe but even if it is so that is so since many years and no reason to
> > introduce versioning in lavc in the same revission as lavu.
> 
> Yes the issue has existed for years (though has become more important
> over time as the number of packaged libraries using FFmpeg has
> increased). But what difference does that time make? I don't see any
> reason why it'd be an argument not to version lavc/lavf.

Iam not arguing not to version lavc/lavf, my argument was just that its
for us no advantage to add the versioning stuff to all libs in the same
time/revission. We could do lavu first (which is easy) then wait a week and
see if any unexpected bugs come up and after that do lavc&lavf.
Of course it is largely Reinhard who will likely do the work and thus
also influence significantly in what order things are done ...


> 
> 
> > > and introducing the new versions smoothly
> > > requires that everything has been built with versioning support _before_
> > > the new lavc/lavf versions appear.
> > 
> > Again this is not correct, applications never need to be rebuild
> > 
> > old soname libavutil needs a rebuild due to a bug in the gnu linker
> > which causes a versioned dependancy to be linked to a unversioned
> > definition even though a correctly versioned definiiton is available.
> > [this bug should be reported]
> 
> Even if you want to rely on the linker to get the right result for
> applications without explicit versioning that changes very little.

it reduces the number of packages needing a rebuild by a large amount


> Rebuilding multiple packages is still needed, and it's still better to
> do it for all of lavc/lavf/lavu at once. 

at the distro level doing it all at once might make sense but iam not any
distros maintainer, i was primarely speaking of ffmpeg svn and here there
is no real point in introducing versioning for all libs at the same time.
Small changes are better if something goes wrong ...


> After the next incompatible
> lavc/lavf change, introducing the new versions smoothly still requires
> that versioned libraries have already been available _before_ the change
> and things have already been rebuilt against them.

unless you fix the linker yes thats what i said ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091207/82df9768/attachment.pgp>



More information about the ffmpeg-devel mailing list