On Fri, Jan 08, 2010 at 11:32:24PM -0500, Matt Turner wrote:
> I don't see any point in using the o32 ABI, so I tried the 2006.1 n32
> stage (the _latest_ is 2006.1...) and after a couple failed attempts,
> I've decided it's too far gone to be of any use.

An attempt to install an almost four year old stage is doomed to fail.
Gentoo has got new EAPI's and such, and the version of Portage shipped
in those stages is probably going to explode immediately after the
initial sync.

o32 has always been the most well-supported MIPS ABI for Gentoo/MIPS
installations. I didn't even do an n32 or n64 stage for the 2007.0
release mainly due to lack of time and such. Consider o32 to be the most
stable ABI for your Gentoo setup as it is today. You could, of course,
easily start experimenting with it as well.

> On top if that, the Gentoo devmanual states [0] that in order to mark
> a package as ~mips, "[t]he package should work on both big and little
> endian systems, on both pure 32 bit and pure 64 bit systems and on
> systems with differing kernel and userland ABIs." That means testing
> on (big endian/little endian) x (32bit/64bit/mixed kernel/user) x
> (o32/n32/n64) == 18 potential combinations. (I guess actually less.
> I'm not sure how you could have an o32-pure-64-bit system for
> instance).

I personally never really cared about little-endian systems and I'd
guess that most of Gentoo/MIPS development team doesn't care either.
It's very difficult to get non-router-sized little-endian MIPS-based
machines, so it is almost impossible to do something even remotely
useful with Gentoo on those machines. Little-endian MIPS porting has
always been done by those who had access to the hardware (for example:
Cobalt machines) and has been silently ignored by everyone else.

Usually you can just stick to testing packages on whatever you are
running, but for most critical system packages, it is really a good idea
to test it on non-o32 ABI's as well.

> God. Let's dump o32 already. That cuts the number to 12. At this
> point, it's still ridiculous to ask a single developer to test this
> many configurations. Split ~mips into ~mips-be and ~mips-le or
> something. This would certainly make it more manageable. Whatever the
> case, we've got to limit the range of possible configurations.

That would require a much more active MIPS team. It may sound silly that
getting rid of an ABI takes time, but getting rid of the "main" ABI is
not a very easy task.

> Well. There are two developers on IRC. I talk to them occasionally,
> but I don't think constant prodding is the way to productivity.

How so? That's how I ended up joining Gentoo/MIPS some years ago.

-- 
Alexander Færøy