Gentoo Archives: gentoo-desktop

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-desktop@l.g.o
Subject: [gentoo-desktop] Re: ffmpeg versions in portage
Date: Thu, 19 Feb 2015 06:47:50
Message-Id: pan$a99d4$504b0cce$2c2601fd$
In Reply to: [gentoo-desktop] ffmpeg versions in portage by Brent Busby
1 Brent Busby posted on Wed, 18 Feb 2015 22:19:37 -0600 as excerpted:
3 > With all the arguing I see in the forums lately about libav versus
4 > ffmpeg, I thought I'd ask an ffmpeg question of a different nature:
5 >
6 > Upstream, the ffmpeg people are releasing 2.5 as "stable." Some people
7 > (who I'm not going to argue with, since I don't really have a position
8 > on it myself) say the ffmpeg developers are reckless. However, I notice
9 > that most other distros are at least shipping 2.2 (perhaps with lots of
10 > distro patches to fix problems?).
11 >
12 > Gentoo's stable ffmpeg is currently 1.2.6, a fully maintained (i.e., not
13 > defunct or deprecated) branch with ffmpeg upstream, apparently
14 > maintained for really conservative users.
15 >
16 > All of this has me wondering...should I unmask? Both 2.2 and 2.5 are
17 > available in Portage as ~amd64 ebuilds. Is anyone here doing this? Does
18 > it unleash the hounds of hell (or the UNIX equivalent, lots of
19 > unpleasant segfaults and codec problems)? I'm mostly wanting better
20 > Bluray/WMV3/VC-1 support, but I don't know how that stands between the
21 > various 1.2/2.2/2.5 branches.
22 >
23 > From talking to people who don't run Gentoo, I've found that it has a
24 > reputation for being bleeding-edge, but at times, I've found to the
25 > contraty that it can actually sometimes be overcautious, making it hard
26 > to tell if you're missing out on things other distros are enjoying
27 > because your upgrades are masked. Sometimes, package versions will stay
28 > masked for months or years just because nobody got around to marking
29 > them stable for amd64 and not because of any actual bugs.
30 >
31 > Anybody running ffmpeg 2.x without issues? If so, which one...2.2 or
32 > 2.5?
34 [Adding this note after I wrote the below. I think it ended up reading
35 harsher than I intended. I know people choose stable for a reason and I
36 really do respect that. Those people simply aren't me, nor that reason
37 mine... and that certainly comes out in the below. But no personal, or
38 even whole-group, offense intended. It's just not me. But it's your
39 machine, not mine, and gentoo wouldn't be gentoo if it didn't respect
40 your ultimate control of your machine, neither would I be me in the same
41 case. So, umm... Read the below with that in mind. =:^) ]
43 I think what you actually want to know (which isn't what you asked), is
44 if anyone running _sta(b)le_ amd64, is running ffmpeg 2.x without issues.
46 Because people running ~amd64, including me, if they're current (I am),
47 are running ffmpeg-2.5.4.
49 And in general, I've not seen issues.
51 However, that's because the various other apps also in ~amd64 have in
52 general already been updated to work with the newer ffmpeg.
54 Which is the problem with stale^h^hble amd64, and sta(b)le gentoo in
55 general. The newer ffmpeg can't be unmasked to sta(b)le until pretty
56 much everything else in sta(b)le has been updated to work with it as well.
58 And in fact, whenever there's something that has gotten as far behind on
59 stable as ffmpeg has, in particular, for stuff like gcc, it's very likely
60 the same general problem. On gentoo, for packages like gcc in
61 particular, even ~amd64 (and ~arch in general) is generally quite behind,
62 because before it's unmasked to ~arch, they want to ensure that all other
63 packages (at the same ~arch) level have been patched to build with it.
64 Which means it takes "forever" to unmask even to ~arch, because of all
65 those other packages that have to be either updated first, or patched to
66 build with the new gcc. Then when all that is done and it hits ~arch,
67 the process starts over for sta(b)le; all those patched packages have to
68 be sta(b)le keyworded before gcc itself can be sta(b)le keyworded.
70 And yes, sometimes that does mean "stable" is "stale", no two ways about
71 it. But it's a choice you make...
73 But at least gentoo does make it real easy to package.keyword specific
74 packages if you like, so you can be sta(b)le on most things while
75 choosing to try arch or even masked versions if you dare.
77 If you like you can do an equery depends ffmpeg, and see which packages
78 that you actually have installed depend on it. You can then research
79 each one to see if the version you currently have merged can function
80 with the newer ffmpeg, and if not, you can of course package.keyword it
81 ~arch at the same time.
83 With a bit of luck all the packages you have installed are already
84 updated and it'll "just work" (perhaps with a rebuild of some of them)
85 for you. If you're not that lucky, but still somewhat lucky, they've at
86 least been updated with blockers or version ranges, so if you go to
87 install the newer ffmpeg, portage will tell you which packages you have
88 to keyword-unmask in ordered to proceed.
90 Of course you also risk that they've not been updated yet, and simply
91 quit working with no explanation, until you figure it out and unmask them
92 so you get the newer version of them too.
94 But at least with an equery depends ffmpeg, you can see how many packages
95 you are risking, and decide whether it's worth the hassle from there, or
96 if it's too much to risk/hassle and you prefer to wait for the full
97 stable update after all.
99 Of course another alternative is to "Dear Interwebs" the solution. You
100 can post your equery results here and see if there's enough other people
101 on sta(b)le but running a newer/package.keyworded ffmpeg with those
102 packages as well, to compare notes. =:^)
104 --
105 Duncan - List replies preferred. No HTML msgs.
106 "Every nonfree program has a lord, a master --
107 and if you use the program, he is your master." Richard Stallman


Subject Author
Re: [gentoo-desktop] Re: ffmpeg versions in portage Brent Busby <brent@×××××××××.org>