| 1 |
Richard Fish wrote: |
| 2 |
>> That won't be necessary. Things mostly works, and when they don't, |
| 3 |
>> users file a bug like the aforementioned one, which should result in |
| 4 |
>> that particular ebuild getting fixed, instead of the bug being marked |
| 5 |
>> INVALID. |
| 6 |
> |
| 7 |
> The thing is, "this particular ebuild" isn't actually broken. Or I |
| 8 |
> guess if it is, then so are <some_potentially_large_number> other |
| 9 |
> ebuilds in the tree, since they probably won't build with old gcc |
| 10 |
> versions either. Ok, most would probably build with gcc 3.3. And |
| 11 |
> maybe even gcc 3.1. But 2.95?? Handling this at the ebuild level is |
| 12 |
> just not a good solution for the general case. |
| 13 |
> |
| 14 |
> -Richard |
| 15 |
|
| 16 |
Well yeah, there's nothing broken w/ the ebuild. And xine-lib is _not_ |
| 17 |
the only thing that just bombs out on sucky compiler version, see fex. |
| 18 |
http://bugs.gentoo.org/show_bug.cgi?id=121501 |
| 19 |
|
| 20 |
There's no sane way to force users to switch their gcc version, so |
| 21 |
messing w/ ebuild deps, profiles or keywords of outdated gcc versions |
| 22 |
won't help... |
| 23 |
|
| 24 |
|
| 25 |
|
| 26 |
-- |
| 27 |
|
| 28 |
jakub |
Archives