| 1 |
On 7/9/06, Molle Bestefich <molle.bestefich@×××××.com> wrote: |
| 2 |
> As far as I can tell, the complaints are about Portage being unable to |
| 3 |
> handle GCC upgrades gracefully for end users. |
| 4 |
|
| 5 |
The thing is, that portage doesn't technically "handle" gcc upgrades. |
| 6 |
The user really needs to do that, and they (should) know to do that |
| 7 |
when they see the new version show up in an "emerge -Duv world". Or |
| 8 |
on GWN. |
| 9 |
|
| 10 |
Ok, so some users are not getting that message. To be honest, I have |
| 11 |
no idea what to do about that. Having dozens (hundreds? all?) |
| 12 |
ebuilds check for a minimum version of gcc doesn't seem very |
| 13 |
effecient. I guess portage could check and warn about an unsupported |
| 14 |
version of gcc being selected for the system compiler, but then I we |
| 15 |
have to figure out exactly what the "supported" versions are, and |
| 16 |
exactly when a version becomes unsupported, as a matter of policy. |
| 17 |
|
| 18 |
But that won't even fix the "problem". The version of xine-lib that |
| 19 |
this bug refers to is a ~x86 version. Should that be expected to |
| 20 |
compile with the stable gcc? Or only with the ~x86 gcc. What if the |
| 21 |
maintainer doesn't intend to stabilize the package until the ~x86 |
| 22 |
version of gcc goes stable? |
| 23 |
|
| 24 |
So I don't think the issue is as simple as either having xine-lib put |
| 25 |
out a warning about a particular gcc version, as that doesn't work in |
| 26 |
the general case. And putting the checks in portage doesn't seem to |
| 27 |
work very well either. |
| 28 |
|
| 29 |
The system as it is now actually seems to work about right...the vast |
| 30 |
majority of stable users upgrade to new versions of gcc as they come |
| 31 |
out, hopefully following the upgrade guide, and never see anything |
| 32 |
fail to build due to the gcc version. Others get informed via other |
| 33 |
means, and hopefully remember for the future. |
| 34 |
|
| 35 |
> That won't be necessary. Things mostly works, and when they don't, |
| 36 |
> users file a bug like the aforementioned one, which should result in |
| 37 |
> that particular ebuild getting fixed, instead of the bug being marked |
| 38 |
> INVALID. |
| 39 |
|
| 40 |
The thing is, "this particular ebuild" isn't actually broken. Or I |
| 41 |
guess if it is, then so are <some_potentially_large_number> other |
| 42 |
ebuilds in the tree, since they probably won't build with old gcc |
| 43 |
versions either. Ok, most would probably build with gcc 3.3. And |
| 44 |
maybe even gcc 3.1. But 2.95?? Handling this at the ebuild level is |
| 45 |
just not a good solution for the general case. |
| 46 |
|
| 47 |
-Richard |
| 48 |
-- |
| 49 |
gentoo-dev@g.o mailing list |
Archives