[FFmpeg-devel] [PATCH 11/11] Make ff_cmap_read_palette static to libavcodec/iff.c. Delete iff.h.

Reinhard Tartler siretart
Wed Jan 26 17:57:54 CET 2011


On Mi, Jan 26, 2011 at 17:30:45 (CET), Ronald S. Bultje wrote:

> Hi,
>
> On Jan 26, 2011, at 10:50 AM, Reinhard Tartler <siretart at tauware.de> wrote:
>
>> On Tue, Jan 25, 2011 at 03:52:10 (CET), Ronald S. Bultje wrote:
>> 
>>> Hi,
>>> 
>>> 2011/1/24 M?ns Rullg?rd <mans at mansr.com>:
>>>> "Ronald S. Bultje" <rsbultje at gmail.com> writes:
>>>>> On Mon, Jan 24, 2011 at 8:29 PM, Diego Elio Petten? <flameeyes at gmail.com> wrote:
>>>>>> The iff.h header only declared one function that is now static, the
>>>>>> libavformat/iff.c source file wasn't using it before. Drop the file
>>>>>> entirely.
>>>>> 
>>>>> I believe we're keeping this one for backwards compatibility. You can
>>>>> put it under an #if VERSION...
>>>> 
>>>> Compatibility with what?  It's not a public interface.
>> 
>> ACK
>> 
>>> It was for Debian, so people can mix and match libavcodec/format
>>> versions. Can the Debian maintainer please remind me why we kept it?
>> 
>> What makes you think so? Since it is not a public header, no application
>> is supposed to be able to reference it.
>> 
>> There may be weird applications that reference the symbol
>> ff_cmap_read_palette, but since Diego has an outstanding research on
>> this issue, I trust him that this is not the case.
>
> It's non-static b/c lavc iff video decoder used it, and we kept it
> there for those poor souls mixing different lavc/f versions.

the thing becomes complicated in case a major bump happens. in that case
it can happen that the library that was not bumped is still on the disk,
and applications that are linked to it still use it. In that case we'd
need to keep it until the next major bump.

I don't see that this is the case here. Am I overlooking something?

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




More information about the ffmpeg-devel mailing list