OK, I'm rambling, and I hope I don't offend anyone here, but I hope this might be useful, or at least food for thought. There are many ebuilds. That's great! The problem is that most of them are broken, because I'm on a somewhat "nonstandard" platform - ia64. OK, fine. I have a relatively rare piece of hardware, why should I expect software to magically work? Well, I should expect it to work because while the *hardware* is nonstandard, that has absolutely nothing to do with the 'image' it presents to portage. GCC is there, binutils are there, and aside from being an LP64 system, that should be the end of story. What is a bit unfortunate is that I see lots of ebuilds fixed for hppa or x86-64, but that someone has to go and manually update them *again* to make them work on ia64. This is only going to keep recurring unless some change is made. I humbly propose (in my gentoo newbieness) that gentoo stop considering a simple list of architectures, and instead develop a hierarchy. There should be not eight, but just two main "platform types": LP32 LP64 from which 'descend' all the other architectures: LP32 -> x86, MIPS3, hppa32 etc LP64 -> amd64, ia64, MIPS4, hppa64 etc and which will take care of every ebuild that does not have inline assembly, or other hardware-specific code (i.e., the vast majority of them.) The alternative is to keep wasting everyone's time, but a happy compromise might be to at least politely inform amd64 developers that if something works on amd64, it will almost certainly work on ia64 and hppa64 also, and conversely, every time an ia64 package is marked stable, it's probably going to be stable on amd64 as well, for example. Reproducible: Always Steps to Reproduce:
This isn't really only a portage thing, it would affect some fundamental processes, so I suggest you write a GLEP about this (see http://glep.gentoo.org).
Apart from a GLEP++ statement, I don't think it would be wise for Gentoo to bump packages for other architectures (even if they're in the same 32/64 bit environment) unless you're able to test them on those architectures. That's policy and ensures a little QA.
I think there are two kinds of QA at stake here: the simple kind: "does this piece of software work?" the Good kind: "is this piece of software written correctly?" I understand that forcing people to test out software is a good thing. But better would be to move towards a world where everything is LP64-clean. That's probably very difficult, so having an LP32/LP64 split is very practical. Then, the only thing one has to do is distinguish software that makes platform assumptions *besides* LP32/LP64 (for example, inline assembly). I think that this would lead to *fewer* problems than simply testing everything piece by piece, since doing that lets all manner of "once-off" hacks creep into Gentoo. Properly flagging software as LP32, LP64 or "arch-specific" would help as software would get a different (and IMHO far more useful) kind of QA: whether or not software that claims or is assumed to be 64-bit clean and portable (one hopes this is or one day will be the vast majority of packages..) actually is. Hmm.
Changing of the hierarchy would be glep material as noted in this bug. Beyond that, multi-lib is starting to do something vaguely similar to what you specified (moreso the grouping). Closing till details/specs are handed to us from an accepted glep/-dev ml discussion.
