Quoting Stephan Kulow
On 14.06.2012 14:33, Stefan Seyfried wrote:
But OTOH this might punish e.g. gcc for no good reason. Example: the "zypper fails with gcc47" mess. Everyone blamed gcc47, but after looking at the valgrind output, it looked to my untrained eye as if the zypper code was the one to blame. But should the gcc guys have to fix others crap just because they now trigger the broken code to actually break? I have no answer for that. No, but the ones wanting gcc updates should be the ones who tell the zypp guys that the new gcc shows a problem in zypper and they should fix it, so gcc update can continue.
It can't be that the gcc update is pushed into factory and then everyone suffers.
Bringing that example around though: how long would you want to give anything else time to integrate? I had the feeling that a few people did a LOT of fixing for GCC 4.7 before it got pushed. Yes, zypp/libzypp was not fixed by the same team: the zypp code is not the 'clearest' base to start working on.. sadly. Zypp being at the 'heart' of course is important, but should also be 'good code'. If any leaf package would have had the same trouble as zypp, it would very likely just be dropped. Shouldn't we be able to turn around here and ask: why is it that zypp can't be fixed to work with gcc 4.7? Why does it take SO long for one of the most central pieces of 'own code' to be fixed? Which leads almost immediately to the question: Can the openSUSE Community sustain a piece of code like zypp/libzypp/satsolver? Dominique (Sorry if you feel I'm too defensive in the matter of the gcc 4.7 upgrade... ) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org