Andreas Barth wrote:
Actually, there is one criterion missing: Does this bug really hurt us bad (enough)? And my current answer to this is no, but of course, you might want to persuade me. :)
...
So, I think we can say that this bug is even forwarded to upstream, as mips Inc is aware of it and working on a fix.
I begin to get the picture.Apparently the MIPS ABI is just plain broken. It contains some sort of impassable hard limit on relocation table size, breaking random packages at random times with no possible fix. Nobody can fix this without changing the ABI.
Lovely. Good grief, I would not want to support this architecture under those circumstances, but as long as it doesn't interfere with supporting other architectures, if you think you can do it, that's fine.
It seems to me that at a minimum, whenever this bug gets hit any fallout should be prevented from interfering with any other architectures. In other words, a GOT table overflow on MIPS should immediately mean ignoring MIPS for purposes of testing propagation of that package and all indirectly dependent packages.
It's a pity there isn't an automated way to do this (except to ignore MIPS for all testing progression). Perhaps the MIPS porters could file the appropriate requests for removal of obsolete binaries promptly, or something.
What the kaffe maintainers did -- uploading a package which was deliberately unbuildable on mips, without requesting removal of old mips binaries, and without restricting the architecture list for kaffe -- was really bizarre and misleading, and I can't think of a single good reason to do it that way.
It would also be a kindness if the reason why GCJ was disabled on MIPS ("MIPS ABI is broken") was listed clearly somewhere.