On 6/16/2021 7:14 PM, Nicolas George wrote:
James Almer (12021-06-16):
I'm not sure what you mean. I would not be against it, it's just that if we
were to merge lavf and lavd, this wouldn't even be something to consider.
Have you not read the discussion? The benefits go way beyond the tiny
lavf-lavd issues.
and why you are
against for other libraries.
Can you be more specific?
When I say "I am for X" and you reply "I am not against Y", with Y⊂X and
Y≠X, you are implicitly saying that you are against X∖Y. I proposed to
restrict to matching versions on all libraries, you replied you were not
against restricting for lavf-lavd, stating implicitly that you are
against it for the libraries.
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.
So, I ask explicitly: are you against restricting to matching versions
for all the libraries? If so, then why?
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.
_______________________________________________
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".
