Quoting Stephan Kulow <coolo(a)suse.de>de>:
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
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?
(Sorry if you feel I'm too defensive in the matter of the gcc 4.7 upgrade... )
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org