[FFmpeg-devel] Compatibility of different library versions (was: avformat: Add internal flags for AV(In|Out)putFormat)

[James Almer]

On 6/17/2021 6:27 AM, Nicolas George wrote:
> James Almer (12021-06-16):
>> Considering this discussion started about lavd and lavf, and at no point in
>> your email you said "all libraries" when suggesting version locking anything
>> (In fact, you mistakenly wrote "only versions from the same version"), i
>> figured it would be obvious i was commenting specifically about lavd<->lavf.
> 
> Ok, I read too much in your wording after you read too little in mine.
> No problem.
> 
>> Of course i am against doing so for all libraries. They are already locked
>> at the major soname level as required, and that's enough.
>> Lavd as is is locking certain lavf's public structs and making it impossible
>> to add new fields to them, which constricts development considerably, so
>> making their locking strict to at least the minor soname level is a very
>> good idea. But this isn't an issue at all for other libraries.
>> I can add new fields to any public lavc struct, compile it and have a lavf
>> that was linked to an old lavc use it at runtime, and it will work just
>> fine.
>> I see no benefit to your suggestion that's worth removing such freedom from
>> the end user.
> 
> I am sorry, but you are not looking hard enough. You are describing ONE
> of the several compatibility issue we have, the one that happens most on
> lavf-lavd.
> 
> But please realize that every single avpriv symbol is a reason to lock
> all libraries version of its own.

Countless avpriv_ symbols would not be gone with any kind of locking. 
Only a couple ones that work as getter/setter to workaround struct 
offsets. And, surprise, all of those are in lavd, which will be gone if 
we version lock it with lavf.

> 
> It is very dense for lavd, but lavd is tiny. There are tons of it on the
> lavc-lavc side, many different from each other and requiring subtly
> different solutions if they need updating.
> 
> Furthermore, what you explained is not a reason to be against, it is the
> absence of reason to be for. Opposing something is not the same thing as
> not supporting it: if you do not care, or if you do not know, you are
> encouraged to neither oppose nor support.
> 
> So, I ask again:
> 
> Do you have a reason to oppose locking all library versions together?

I already gave you the reason why I'm *against* it. I find it insulting 
that you completely disregard it and then ask again if i have one, 
instead of if i have another.

Version locking all libraries adds a constrain that's not required, 
brings no worthwhile benefits, and removes freedom for the end user.
And I'll mention that your wish to do this certainly feels like a 
concealed attempt to try to push decisions and changes closer towards 
your personal end goal of merging all libraries.

I have nothing else to say. I support version locking lavf and lavd, and 
completely oppose version locking every other library for the reasons i 
already gave you.