Richard Fish wrote:
The expectation here is that when a new version of gcc is stabilized, that users will upgrade to that in a reasonable amount of time, and use that (by selecting it with gcc-config) for compiling all new updates. FYI, gcc-3.4.4-r1 was stabilized on 2-Dec-2005, and the current stable is 3.4.6-r1 since May 29th.
I don't see how that information is conveyed to the user. Portage shouts about upgrading to a new profile from time to time, but it never tells anyone to upgrade GCC. Perhaps it should, if that's what the devs expect people to do.
The devs can *not* be expected to verify that all software in portage builds with all versions of gcc in portage.
Of course not.
The alternative here is that old versions of gcc disappear from portage, but that causes a problem for those who need those versions for some reason, such as compiling non-gentoo software.
Yes, ok. That's a bad alternative. Thus it seems that there's no appropriate mechanism to handle new GCC versions in Portage, which again makes sense wrt. the complaints.
> Nothing personal against Jakub Moc who probably has a lot to do, but > the handling of relevant issues raised in the bugzilla is just > unacceptable. What, exactly, do you find unacceptable in "Your gcc version is outdated and unsupported"?
Nothing? I find it unacceptable that the bug is marked INVALID when it clearly describes a relevant issue. As far as I can tell, the complaints are about Portage being unable to handle GCC upgrades gracefully for end users. You could perhaps argue that the issue started out as "why do I get this error message" and ended up being "why doesn't Portage handle GCC upgrades gracefully", which is of course a slightly different thing. But it should be clear to anyone reading the bug what the real issue is. I'm even willing to bet that if I create a new bug describing the Portage issue, with no mention of the specific xine ebuild, it will get closed as a duplicate of this bug anyway. I've got case studies proving that this is what happens, heh.
I suppose portage could be enhanced to have a is_gcc_version_supported() check, but I'm not sure how useful that would be.
If that would enable ebuild maintainers to flag xine as requiring 3.4 for compilation, then that would definitely solve the issue described in the bug. I'd say that's _very useful_ to the end user. You could argue that only a couple of people has spent the time to create a bugzilla login and lodge a complaint in the bug, but there's probably more out there. We can count the duplicates in a couple of months and see ;-). And as newer GCC features are used throughout, the situation will probably happen more in the future.
> What's the state of Portage and Gentoo in general? Is there not > enough hands to do a proper job? Or is it just that none of the devs > see what's wrong because bugs are wrongly being closed marked > "INVALID" such as the above when they're in fact not? If you want to test compiling every version of every package in portage with all 21 versions (16 if you assume all -rX versions are compatible, or /only 9/ if you only consider stable x86 versions) of gcc that are currently in portage, and submit patches when things fail, go ahead.
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. -- [email protected] mailing list
