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. 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? Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
