Shared publicly  - 
So what's it been like half a decade that debian has been doing this multiarch stuff, and I still have to make local changes to fundamental things like glibc just to get an equivalent install to what the distro gets?

As the GLIBC release manager I just want to install the thing on one of
my sparc machines and do some basic install smoke testing.  But I've lost several afternoons trying to figure out what still-not-merged-upstream local changes I have to apply to get the multiarch stuff to all pan out properly.  Otherwise I'll get a botched install and it will have nothing to do with any bug upstream.

This is rather unacceptable.  I really don't care what gains debian gets from this mutliarch crap, you are crippling the upstream maintainers from testing these fundamental tools (and thus working more closely with you) by doing things like this.

If it's going to take more than a year to upstream your stuff, you can't deploy it in the distro first.  Otherwise you have absolutely no incentive to do whatever it takes to get upstream acceptance of all of your changes, and it's just going to languish and cause insane amounts of pain for any upstream maintainer who wants to get work done on your system.

This sounds bitter, but I've been dealing with this crap this entire time in all of gcc, binutils, and glibc.  It's a complete nightmare seemingly without end.
Adam Conrad's profile photoCarlos O'Donell's profile photoWook Wookey's profile photoSaulius Krasuckas's profile photo
As far as I know we suffered some chicken and egg issues with upstreaming various toolchain bits, but doko recently told me all the gcc stuff was finally accepted, so I might see what we still need to land in glibc for 2.18.
rtld paths being different from slibdir, which is local-rtld.diff, and then there is local-ldconfig-multiarch.diff
And, to be somewhat fair, multiarch only landed in Debian glibc a little over a year ago in unstable, it's been far less than half a decade.
It's definitely been much longer than that, I remember getting killed trying to do gcc development because of /lib/sparc-linux-gnu/ at least two winters ago.
This also bugs me, but to be honest upstream was no angel here... water under the bridge, lets move forward with Adam's help. Adam I know you to be a smart and able hacker, let's get this sorted over the next 6 month development cycle?
Is it just me, or is Carlos hitting on me?
Whatever it takes to bring more volunteers to the project ;-)
I came rather late to this, but according to the history at multiarch specification work started in 2004, but nothing much actually happenned on code until the spec was finalised in 2nd half of 2010 (which is about when I got interested). Initial glibc patches must have been written around then, but as Adam says, only got into the distro around end 2011.

You (David) are quite right that we didn't handle this upstream very well at all, and that has made the whole thing more painful than it needed to be. I saw everyone involved doing their best be inclusive, trying to avoid the exact problems we have in fact ended up with, but clearly we didn't get upstream glibc (and gcc) people involved soon enough and that's been a pain for everyone. I know I didn't even know who those people were until quite recently (It seems to me that both arm and Debian/Ubuntu  - the circles I move in - have been quite poorly connected to glibc dev for some time).

I'd echo Carlos's sentiment: Lets put previous cock-ups behind us and try to get this sorted. I find multiarch to be a really useful and significant development and I'd really like to get to a state where it's easily available to people/distros that want to use it, and not causing undue pain for people like David. I'll try and help with that, but I only looked into glibc a few months back, and then almost entirely at packaging, so my contribution is necessarily limited.