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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]