1 |
On Thu, 19 Feb 2015, Duncan wrote: |
2 |
|
3 |
> [Adding this note after I wrote the below. I think it ended up |
4 |
> reading harsher than I intended. I know people choose stable for a |
5 |
> reason and I really do respect that. Those people simply aren't me, |
6 |
> nor that reason mine... and that certainly comes out in the below. |
7 |
> But no personal, or even whole-group, offense intended. It's just not |
8 |
> me. But it's your machine, not mine, and gentoo wouldn't be gentoo if |
9 |
> it didn't respect your ultimate control of your machine, neither would |
10 |
> I be me in the same case. So, umm... Read the below with that in |
11 |
> mind. =:^) ] |
12 |
|
13 |
Well, it's mostly stable. I have a rather long package.keywords file |
14 |
full of things I've allowed ~amd64 on, and I've been careful about which |
15 |
packages those are. Some are even live ebuilds pulled from GIT. |
16 |
|
17 |
The main reason I'm running stable is because this machine is used for |
18 |
audio recording and music production, and I need it to work. I have |
19 |
quite a bit of experience in chasing down problems, but I'd like to keep |
20 |
that to a minimum. |
21 |
|
22 |
And no, I don't want a binary distro. Those have their own problems. |
23 |
|
24 |
> I think what you actually want to know (which isn't what you asked), is |
25 |
> if anyone running _sta(b)le_ amd64, is running ffmpeg 2.x without issues. |
26 |
> |
27 |
> Because people running ~amd64, including me, if they're current (I am), |
28 |
> are running ffmpeg-2.5.4. |
29 |
> |
30 |
> And in general, I've not seen issues. |
31 |
|
32 |
Ok, well that's basically what I was wanting to know, since it was the |
33 |
stability of ffmpeg 2.5 itself I was wondering about. |
34 |
|
35 |
> However, that's because the various other apps also in ~amd64 have in |
36 |
> general already been updated to work with the newer ffmpeg. |
37 |
> |
38 |
> Which is the problem with stale^h^hble amd64, and sta(b)le gentoo in |
39 |
> general. The newer ffmpeg can't be unmasked to sta(b)le until pretty |
40 |
> much everything else in sta(b)le has been updated to work with it as well. |
41 |
|
42 |
Yes, for that reason, I will very likely end up keeping 1.2 for awhile. |
43 |
I only unmask when it's possible to do so without a lot of complication. |
44 |
|
45 |
> And in fact, whenever there's something that has gotten as far behind on |
46 |
> stable as ffmpeg has, in particular, for stuff like gcc, it's very likely |
47 |
> the same general problem. On gentoo, for packages like gcc in |
48 |
> particular, even ~amd64 (and ~arch in general) is generally quite behind, |
49 |
> because before it's unmasked to ~arch, they want to ensure that all other |
50 |
> packages (at the same ~arch) level have been patched to build with it. |
51 |
> Which means it takes "forever" to unmask even to ~arch, because of all |
52 |
> those other packages that have to be either updated first, or patched to |
53 |
> build with the new gcc. Then when all that is done and it hits ~arch, |
54 |
> the process starts over for sta(b)le; all those patched packages have to |
55 |
> be sta(b)le keyworded before gcc itself can be sta(b)le keyworded. |
56 |
> |
57 |
> And yes, sometimes that does mean "stable" is "stale", no two ways about |
58 |
> it. But it's a choice you make... |
59 |
|
60 |
I know...and I can wait, if it's going to cause a lot of interdependency |
61 |
problems with other packages. I've found that stuff does usually make |
62 |
it to stable eventually, so I don't really have a cow about it. |
63 |
|
64 |
> But at least gentoo does make it real easy to package.keyword specific |
65 |
> packages if you like, so you can be sta(b)le on most things while |
66 |
> choosing to try arch or even masked versions if you dare. |
67 |
|
68 |
This is one of the biggest reasons I run Gentoo instead of a binary |
69 |
distro. Debian-based distros have APT-pinning, but it doesn't work |
70 |
nearly as well, because binary packages have already been compiled |
71 |
against the libraries they were meant for. You can do your own |
72 |
backports, but that's even more special treatment to hassle you with. |
73 |
Most of the time, if you unmask a package on Gentoo, it just compiles |
74 |
against what you have, and it just works, now, and after future system |
75 |
upgrades. |
76 |
|
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. |
82 |
|
83 |
Mostly I just wondered if anyone could tell me if ffmpeg 2.5 itself is |
84 |
fundamentally broken in some way. Sounds like it's fine... |
85 |
|
86 |
-- |
87 |
+ Brent A. Busby + "We've all heard that a million monkeys |
88 |
+ Sr. UNIX Systems Admin + banging on a million typewriters will |
89 |
+ University of Chicago + eventually reproduce the entire works of |
90 |
+ James Franck Institute + Shakespeare. Now, thanks to the Internet, |
91 |
+ Materials Research Ctr + we know this is not true." -Robert Wilensky |