[FFmpeg-devel] [PATCH] restoring binary compatibility with ffmpeg 0.5

[Reinhard Tartler]

On Wed, Jun 09, 2010 at 03:00:15 (CEST), Michael Niedermayer wrote:

> On Wed, Jun 09, 2010 at 12:59:18AM +0100, M?ns Rullg?rd wrote:
>> Reinhard Tartler <siretart at tauware.de> writes:
>> 
>> > On Tue, Jun 08, 2010 at 20:44:41 (CEST), Michael Niedermayer wrote:
>> >
>> >> On Tue, Jun 08, 2010 at 04:41:19PM +0200, Reinhard Tartler wrote:
>> >>> On Mon, Jun 07, 2010 at 10:20:45 (CEST), Reinhard Tartler wrote:
>> >>> 
>> >>> > On Mo, Jun 07, 2010 at 10:02:19 (CEST), M?ns Rullg?rd wrote:
>> >>> >
>> >>> >> Reinhard Tartler <siretart at tauware.de> writes:
>> >>> >>
>> >>> >>> On Mo, Jun 07, 2010 at 08:02:54 (CEST), Reimar D?ffinger wrote:
>> >>> >>>
>> >>> >>>> On Mon, Jun 07, 2010 at 07:52:11AM +0200, Reinhard Tartler wrote:
>> >>> >>>>> void av_init_packet(AVPacket *pkt) av_weak_alias(av_init_packet);
>> >>> >>>>> void av_init_packet(AVPacket *pkt)
>> >>> >>>>> {
>> >>> >>>>>     av_log(NULL, AV_LOG_WARNING, "diverting av_*_packet function calls to libavcodec. Recompile to improve performance\n");
>> >>> >>>>>     av_init_packet(pkt);
>> >>> >>>>
>> >>> >>>> ff_internal_init_packet() and add one such to lavc.
>> >>> >>>> Either way, we should make sure we have a solution the next time.
>> >>> >>>> Since the @LIBAVFORMAT version is not accepted in lavc, does that
>> >>> >>>> mean no matter what we do, we will always break ABI if we move code?!
>> >>> >>>
>> >>> >>> if I understand you correctly, you not only consider ABI breakages
>> >>> >>> between releases, but also between any svn revision? Then I fear yes.
>> >>> >>> However, the break is already there since quite some time, and fixing it
>> >>> >>> to have it compatible to ffmpeg 0.5 has (or at least should have)
>> >>> >>> priority, IMO.
>> >>> >>
>> >>> >> For the 0.6 release possibly.  For trunk I don't think that is
>> >>> >> important.
>> >>> >
>> >>> > Agreed. Still, I'd prefer to not do drastic measures in 0.6 like
>> >>> > prematurely bumping soname or something. How do people feel to apply my
>> >>> > propsed "half-fix" to 0.6 only, and bump soname in trunk?
>> >>> 
>> >>> The discussion on this thread was very vivid but has now ended rather
>> >>> abruptly, and this question remains unanswered.
>> >>> 
>> >>> Does anyone object to have this "half-fix" in 0.6 now, and leave it an
>> >>> open issue for trunk until we either have found a better fix or bumped
>> >>> SONAME? If someone needs more time to think about this, please say so.
>> >>
>> >> i have no awnser atm but i have a question
>> >> how do we move symbols in the future from lavf->lavc / lavc->lavu ?
>> >> this is something we have to do occasionally, and bumping soname is imo
>> >> not reasonable for this.
>> >
>> > I agree that it is pretty annoying, but I don't think it's unreasonable.
>> 
>> It seems to be an unavoidable effect of the symbol versioning.
>> Considering that symbol versioning solved an actually observed
>> problem, that this issue has not yet been fingered in the wild, and
>> that symbol moves like this are in fact quite rare, I agree with this
>> assessment.
>
> stefano just moved the eval code from lavc to lavu
> so i dont know, maybe we are just unluky to already have teh second
> such move but it doesnt feel all that rare to me

perhaps we can schedule and do such moves in batch?

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