Re: Re: ffmpeg versions in portage

On Thu, 19 Feb 2015, Duncan wrote:

> [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. =:^) ]

Well, it's mostly stable.  I have a rather long package.keywords file 
full of things I've allowed ~amd64 on, and I've been careful about which 
packages those are.  Some are even live ebuilds pulled from GIT.

The main reason I'm running stable is because this machine is used for 
audio recording and music production, and I need it to work.  I have 
quite a bit of experience in chasing down problems, but I'd like to keep 
that to a minimum.

And no, I don't want a binary distro.  Those have their own problems.

> 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.

Ok, well that's basically what I was wanting to know, since it was the 
stability of ffmpeg 2.5 itself I was wondering about.

> 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.

Yes, for that reason, I will very likely end up keeping 1.2 for awhile. 
I only unmask when it's possible to do so without a lot of complication.

> 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...

I know...and I can wait, if it's going to cause a lot of interdependency 
problems with other packages.  I've found that stuff does usually make 
it to stable eventually, so I don't really have a cow about it.

> 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.

This is one of the biggest reasons I run Gentoo instead of a binary 
distro.  Debian-based distros have APT-pinning, but it doesn't work 
nearly as well, because binary packages have already been compiled 
against the libraries they were meant for.  You can do your own 
backports, but that's even more special treatment to hassle you with. 
Most of the time, if you unmask a package on Gentoo, it just compiles 
against what you have, and it just works, now, and after future system 
upgrades.

> 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.

Mostly I just wondered if anyone could tell me if ffmpeg 2.5 itself is 
fundamentally broken in some way.  Sounds like it's fine...

-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ James Franck Institute +  Shakespeare.  Now, thanks to the Internet,
+ Materials Research Ctr +  we know this is not true." -Robert Wilensky