Re: ffmpeg versions in portage

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:
>=20
> 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 notic=
e
> that most other distros are at least shipping 2.2 (perhaps with lots of
> distro patches to fix problems?).
>=20
> Gentoo's stable ffmpeg is currently 1.2.6, a fully maintained (i.e., no=
t
> defunct or deprecated) branch with ffmpeg upstream, apparently
> maintained for really conservative users.
>=20
> 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? Doe=
s
> 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.
>=20
> 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 sta=
y
> masked for months or years just because nobody got around to marking
> them stable for amd64 and not because of any actual bugs.
>=20
> 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 =20
harsher than I intended.  I know people choose stable for a reason and I=20
really do respect that.  Those people simply aren't me, nor that reason=20
mine... and that certainly comes out in the below.  But no personal, or=20
even whole-group, offense intended.  It's just not me.  But it's your=20
machine, not mine, and gentoo wouldn't be gentoo if it didn't respect=20
your ultimate control of your machine, neither would I be me in the same=20
case.  So, umm... Read the below with that in mind. =3D:^) ]

I think what you actually want to know (which isn't what you asked), is=20
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),=20
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=20
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=20
general.  The newer ffmpeg can't be unmasked to sta(b)le until pretty=20
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=20
stable as ffmpeg has, in particular, for stuff like gcc, it's very likely=
=20
the same general problem.  On gentoo, for packages like gcc in=20
particular, even ~amd64 (and ~arch in general) is generally quite behind,=
=20
because before it's unmasked to ~arch, they want to ensure that all other=
=20
packages (at the same ~arch) level have been patched to build with it. =20
Which means it takes "forever" to unmask even to ~arch, because of all=20
those other packages that have to be either updated first, or patched to=20
build with the new gcc.  Then when all that is done and it hits ~arch,=20
the process starts over for sta(b)le; all those patched packages have to=20
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=20
it.  But it's a choice you make...

But at least gentoo does make it real easy to package.keyword specific=20
packages if you like, so you can be sta(b)le on most things while=20
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=20
that you actually have installed depend on it.  You can then research=20
each one to see if the version you currently have merged can function=20
with the newer ffmpeg, and if not, you can of course package.keyword it=20
~arch at the same time.

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

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

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

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

--=20
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