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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
