On 7/9/06, Molle Bestefich <[EMAIL PROTECTED]> wrote:
As far as I can tell, the complaints are about Portage being unable to handle GCC upgrades gracefully for end users.
The thing is, that portage doesn't technically "handle" gcc upgrades. The user really needs to do that, and they (should) know to do that when they see the new version show up in an "emerge -Duv world". Or on GWN. Ok, so some users are not getting that message. To be honest, I have no idea what to do about that. Having dozens (hundreds? all?) ebuilds check for a minimum version of gcc doesn't seem very effecient. I guess portage could check and warn about an unsupported version of gcc being selected for the system compiler, but then I we have to figure out exactly what the "supported" versions are, and exactly when a version becomes unsupported, as a matter of policy. But that won't even fix the "problem". The version of xine-lib that this bug refers to is a ~x86 version. Should that be expected to compile with the stable gcc? Or only with the ~x86 gcc. What if the maintainer doesn't intend to stabilize the package until the ~x86 version of gcc goes stable? So I don't think the issue is as simple as either having xine-lib put out a warning about a particular gcc version, as that doesn't work in the general case. And putting the checks in portage doesn't seem to work very well either. The system as it is now actually seems to work about right...the vast majority of stable users upgrade to new versions of gcc as they come out, hopefully following the upgrade guide, and never see anything fail to build due to the gcc version. Others get informed via other means, and hopefully remember for the future.
That won't be necessary. Things mostly works, and when they don't, users file a bug like the aforementioned one, which should result in that particular ebuild getting fixed, instead of the bug being marked INVALID.
The thing is, "this particular ebuild" isn't actually broken. Or I guess if it is, then so are <some_potentially_large_number> other ebuilds in the tree, since they probably won't build with old gcc versions either. Ok, most would probably build with gcc 3.3. And maybe even gcc 3.1. But 2.95?? Handling this at the ebuild level is just not a good solution for the general case. -Richard -- [email protected] mailing list
