[gentoo-desktop] Re: ffmpeg versions in portage

[Duncan]

Brent Busby posted on Wed, 18 Feb 2015 22:19:37 -0600 as excerpted:

> With all the arguing I see in the forums lately about libav versus
> ffmpeg, I thought I'd ask an ffmpeg question of a different nature:
>
> Upstream, the ffmpeg people are releasing 2.5 as "stable."  Some people
> (who I'm not going to argue with, since I don't really have a position
> on it myself) say the ffmpeg developers are reckless.  However, I notice
> that most other distros are at least shipping 2.2 (perhaps with lots of
> distro patches to fix problems?).
>
> Gentoo's stable ffmpeg is currently 1.2.6, a fully maintained (i.e., not
> defunct or deprecated) branch with ffmpeg upstream, apparently
> maintained for really conservative users.
>
> All of this has me wondering...should I unmask?  Both 2.2 and 2.5 are
> available in Portage as ~amd64 ebuilds.  Is anyone here doing this? Does
> it unleash the hounds of hell (or the UNIX equivalent, lots of
> unpleasant segfaults and codec problems)?  I'm mostly wanting better
> Bluray/WMV3/VC-1 support, but I don't know how that stands between the
> various 1.2/2.2/2.5 branches.
>
> From talking to people who don't run Gentoo, I've found that it has a
> reputation for being bleeding-edge, but at times, I've found to the
> contraty that it can actually sometimes be overcautious, making it hard
> to tell if you're missing out on things other distros are enjoying
> because your upgrades are masked.  Sometimes, package versions will stay
> masked for months or years just because nobody got around to marking
> them stable for amd64 and not because of any actual bugs.
>
> Anybody running ffmpeg 2.x without issues?  If so, which one...2.2 or
> 2.5?

[Adding this note after I wrote the below.  I think it ended up reading  
harsher than I intended.  I know people choose stable for a reason and I 
really do respect that.  Those people simply aren't me, nor that reason 
mine... and that certainly comes out in the below.  But no personal, or 
even whole-group, offense intended.  It's just not me.  But it's your 
machine, not mine, and gentoo wouldn't be gentoo if it didn't respect 
your ultimate control of your machine, neither would I be me in the same 
case.  So, umm... Read the below with that in mind. =:^) ]

I think what you actually want to know (which isn't what you asked), is 
if anyone running _sta(b)le_ amd64, is running ffmpeg 2.x without issues.

Because people running ~amd64, including me, if they're current (I am), 
are running ffmpeg-2.5.4.

And in general, I've not seen issues.

However, that's because the various other apps also in ~amd64 have in 
general already been updated to work with the newer ffmpeg.

Which is the problem with stale^h^hble amd64, and sta(b)le gentoo in 
general.  The newer ffmpeg can't be unmasked to sta(b)le until pretty 
much everything else in sta(b)le has been updated to work with it as well.

And in fact, whenever there's something that has gotten as far behind on 
stable as ffmpeg has, in particular, for stuff like gcc, it's very likely 
the same general problem.  On gentoo, for packages like gcc in 
particular, even ~amd64 (and ~arch in general) is generally quite behind, 
because before it's unmasked to ~arch, they want to ensure that all other 
packages (at the same ~arch) level have been patched to build with it.  
Which means it takes "forever" to unmask even to ~arch, because of all 
those other packages that have to be either updated first, or patched to 
build with the new gcc.  Then when all that is done and it hits ~arch, 
the process starts over for sta(b)le; all those patched packages have to 
be sta(b)le keyworded before gcc itself can be sta(b)le keyworded.

And yes, sometimes that does mean "stable" is "stale", no two ways about 
it.  But it's a choice you make...

But at least gentoo does make it real easy to package.keyword specific 
packages if you like, so you can be sta(b)le on most things while 
choosing to try arch or even masked versions if you dare.

If you like you can do an equery depends ffmpeg, and see which packages 
that you actually have installed depend on it.  You can then research 
each one to see if the version you currently have merged can function 
with the newer ffmpeg, and if not, you can of course package.keyword it 
~arch at the same time.

With a bit of luck all the packages you have installed are already 
updated and it'll "just work" (perhaps with a rebuild of some of them) 
for you.  If you're not that lucky, but still somewhat lucky, they've at 
least been updated with blockers or version ranges, so if you go to 
install the newer ffmpeg, portage will tell you which packages you have 
to keyword-unmask in ordered to proceed.

Of course you also risk that they've not been updated yet, and simply 
quit working with no explanation, until you figure it out and unmask them 
so you get the newer version of them too.

But at least with an equery depends ffmpeg, you can see how many packages 
you are risking, and decide whether it's worth the hassle from there, or 
if it's too much to risk/hassle and you prefer to wait for the full 
stable update after all.

Of course another alternative is to "Dear Interwebs" the solution.  You 
can post your equery results here and see if there's enough other people 
on sta(b)le but running a newer/package.keyworded ffmpeg with those 
packages as well, to compare notes. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman