On Wed, 7 Nov 2018 09:57:36 -0500 Ian Stakenvicius <a...@gentoo.org> wrote:
> On 2018-11-06 11:21 a.m., Alexis Ballier wrote: > > On Tue, 6 Nov 2018 11:09:17 -0500 > > Rich Freeman <ri...@gentoo.org> wrote: > > > >> On Tue, Nov 6, 2018 at 10:57 AM Alexis Ballier > >> <aball...@gentoo.org> wrote: > >>> > >>> On Tue, 06 Nov 2018 17:08:22 +0200 > >>> Mart Raudsepp <l...@gentoo.org> wrote: > >>> > >>>> It is not GStreamer fault that ffmpeg breaks API and ABI without > >>>> parallel installability, much less so the distro maintainers of > >>>> it. If you/upstream don't make it parallel installable, then this > >>>> is what you get. > >>> > >>> Are you, seriously, suggesting this is the solution to all > >>> problems here ? > >>> > >> > >> It isn't the only solution, but it is one sane upgrade path. You > >> can't expect everybody to update their software overnight when the > >> API changes. That means you have to support the old API for a > >> while when you introduce a new one, otherwise you end up with some > >> software that doesn't work with the old version, and some software > >> that doesn't work with the new version. > > > > > > These days, only symbols/constants that have been deprecated (and > > marked as such) for a couple of releases are removed. This means > > people see warnings for more than one year before seeing them gone > > for good. The problem here is not "overnight changes" but rather > > consumers not paying attention to those warnings, or worse, nobody > > ever seeing those because it's unmaintained. > > > > But we aren't upstream most of the time, and if upstreams are pegging > their ffmpeg to a single version they don't bother to try the newer > one to find out the errors. Take Kodi, v17.x is pegged to no newer > than ffmpeg-3.3.x as I recall, and has been blocking even v3.4's > installation for the year'ish it's been in the gentoo repo. > > So this "people see warnings" thing, it really doesn't apply, unless > you (A) have the desire and resources to build and maintain a patch > for upstream, and (B) have an upstream with the desire and resources > to support more than the one version of ffmpeg for a given release > set. Both, IMO, are in very short supply. > Believe me, it's far easier to do this than maintaining several slotted versions. See the amount of work done for e.g. gtk, qt, wxwidgets, etc. and I'm not even counting backporting security fixes nor patching tens of packages to "use the proper slot". Note that the (B) desire is usually mostly killed by people claiming multiple versions should be supported without any idea of the implications this has. Fortunately, there's only very few upstreams left that consider ffmpeg so special that they want to bundle or force an old buggy and vulnerable version.
