On Tue, Mar 6, 2012 at 7:05 PM, Jonas Smedegaard <d...@jones.dk> wrote: > On 12-03-06 at 06:33pm, Reinhard Tartler wrote: >> On Tue, Mar 6, 2012 at 6:25 PM, Jonas Smedegaard <d...@jones.dk> wrote: >> > On 12-03-06 at 05:51pm, Reinhard Tartler wrote: >> >> On Tue, Mar 6, 2012 at 2:10 PM, Fabian Greffrath >> >> <fab...@greffrath.com> wrote: >> >> > Hi Laurento, >> >> > >> >> > Am 06.03.2012 13:54, schrieb Laurento: >> >> > >> >> >> I've just upgraded ffmpeg and now it simply doesn't work... >> >> >> $ /usr/bin/ffmpeg: relocation error: >> >> >> /usr/lib/x86_64-linux-gnu/libavformat.so.53: symbol >> >> >> avcodec_is_open, version LIBAVCODEC_53 not defined in file >> >> >> libavcodec.so.53 with link time reference >> >> > >> >> > >> >> > this symbol has been added in Version 4:0.8-2. Please update your >> >> > libavcodec53 package to that version as well. >> >> > >> >> > Reinhard, how about bumping shlibs when symbols are added? ;) >> >> >> >> Ouch, yes, that's indeed a bug in the package and needs to be fixed in >> >> 4:0.8-3. >> > >> > Using symbols files would catch this, causing a build failure until >> > corrected. >> > >> > I offer to add that, if noone objects. >> >> I looked into that last year (or the year before). The problem is that >> symbol files do not seem to support alternative dependencies in a way >> that allow applications to link either against libav or their >> libav-extra counterparts. >> >> The other problem with symbol files are that libavcodec and >> libavformat still export too many private symbols. This is being >> worked on upstream, which is why libav 0.9 will bump SONAMEs again. >> >> If you want to implement symbols file without replacing the current >> shlibs file (which on the first sight seems pretty pointless), then >> I'd have no objections. > > Thanks for elaborating! > > I believe the use of symbols files override shlibs, so do not expect to > be able to support that requirement of yours, even if it did make sense > (I fail to understand what use that would be).
Mainly sanity checks about exported/dropped symbols. The usefulness about this might be debatable, since upstream (and I) do extensive code reviews to ensure compatibility, but another check never hurts. > I do recall now that in our earlier discussion the main issue was > private symbols. Thanks for reminding me :-) Nice to hear that work is > ongoing on improving that. > > Regarding libav-extra I would prefer that source package to be dropped, > but let's rehash that discussion later... :-) Ask in a couple of months again. I think there might be a solution then, but let's see. -- regards, Reinhard _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers