[FFmpeg-devel] [PATCH 11/11] Make ff_cmap_read_palette static to libavcodec/iff.c. Delete iff.h.
Ronald S. Bultje
rsbultje
Wed Jan 26 18:00:13 CET 2011
Hi,
On Wed, Jan 26, 2011 at 11:57 AM, Reinhard Tartler <siretart at tauware.de> wrote:
> 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?
What if people don't upgrade their SVN/git every day? It could be that
people update from a specific point in time to a specific point in
time where the above bug does happen.
I'm not against removing the symbol, this is just what was brought up
a while ago as for why we kept the symbol...
Ronald
More information about the ffmpeg-devel
mailing list