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