| 1 |
Richard Fish wrote: |
| 2 |
> Having dozens (hundreds? all?) ebuilds check for a minimum version |
| 3 |
|
| 4 |
Probably just the ebuilds that happen to use new GCC features before |
| 5 |
the mass of the general public has changed to that version. But yes, |
| 6 |
a minimum version constraint could theoretically end up in a lot of |
| 7 |
packages. |
| 8 |
|
| 9 |
> of gcc doesn't seem very effecient. |
| 10 |
|
| 11 |
I can't see why it would not be efficient? |
| 12 |
|
| 13 |
> I don't think the issue is as simple as either having xine-lib put |
| 14 |
> out a warning about a particular gcc version, as that doesn't work |
| 15 |
> in the general case. |
| 16 |
|
| 17 |
Obviously any solution implemented should work for all ebuilds, not |
| 18 |
just xine-lib. |
| 19 |
|
| 20 |
> And putting the checks in portage doesn't seem to work very well |
| 21 |
> either. |
| 22 |
|
| 23 |
I fail to see how a test in the ebuild for the active |
| 24 |
GCC compiler version wouldn't work? |
| 25 |
|
| 26 |
> The system as it is now actually seems to work about right... the |
| 27 |
> vast majority of stable users upgrade to new versions of gcc as they |
| 28 |
> come out |
| 29 |
|
| 30 |
Really? |
| 31 |
How do you gather? |
| 32 |
I'd think that most users hadn't even run into this problem (yet), |
| 33 |
because many source code maintainers strive to be able to compile with |
| 34 |
as old a version of GCC as possible.. |
| 35 |
-- |
| 36 |
gentoo-dev@g.o mailing list |
Archives