This is a discussion about multi-arch from #debian-devel from February, 2004. Thanks to braindmg for the IRC log. This version is edited to only contain the multiarch relevant stuff

   1 00:44 <Mithrandir> DanielS:
   2 00:44 <doogie> is that sucky too?
   3 00:44 * Snow-Man/#debian-devel blinks.
   4 00:44 <Mithrandir> doogie: the multiarch proposal?  shouldn't be.
   5 00:44 <Mithrandir> Snow-Man: please comment on it
   6 00:44 <Snow-Man> a'ight, I'll take a look..
   7 00:45 <Mithrandir> thx
   8 00:45 <Snow-Man> I gotta leave in a few minutes but if I don't get a chance now I will later. :)
   9 00:45 <Mithrandir> just mail me any comments
  10 00:45 <DanielS> Mithrandir: looks interesting, but a lot of work. i don't see any other better proposals to do it right, tho. thanks for taking the time.
  11 00:45 <doogie> Mithrandir: yes, it sucks.
  12 00:46 <Snow-Man> Mithrandir: Alright, well, first off, the first two sentences aren't *actually* directly associated as is implied.
  13 00:46 <Mithrandir> doogie: oh, why?
  14 00:46 <doogie> because you are saying what has to be done, without discussing with those who have to implement it.
  15 00:47 <Snow-Man> Anyone can implement it.
  16 00:47 <DanielS> doogie: ever stop to think that it's a proposal out there for discussion?
  17 00:47 <Snow-Man> Now, bringing up technical issues that will affect implementation would be useful.
  18 00:47 <Snow-Man> Suggestions, even better.
  19 -:- Kamion [] has joined #debian-devel
  20 00:49 <doogie> I don't like the multi-arch field.
  21 00:49 <doogie> requires rebuilding debs.
  22 00:49 <Mithrandir> oh?  It'll default to "No" if it's not there.
  23 00:50 <Snow-Man> I dunno about dumpmachine.
  24 00:50 <doogie> so when do you set it to yes?
  25 00:50 <Snow-Man> Not entirely sure about arch-specific header files either.
  26 00:50 <Skif> Or rather, when do you not set it to 'yes'?
  27 00:50 <Skif> Seems like you'd always want it to be true for everything?
  28 00:50 <doogie> a pure x86 archive won't need it.  so, uploads to x86 won't have the flag set.
  29 00:50 <Mithrandir> you set it to yes if you don't have files outside of /{usr,}/$(gcc -dumpmachine)
  30 00:50 <doogie> then when one tries to install x86 on x86-64, the flag won't be set, so what will happen?
  31 00:51 <doogie> Mithrandir: you didn't say that.
  32 00:51 <Skif> Mithrandir: but there is no such dir now, so we should break FHS?
  33 00:51 <Mithrandir> Skif: so?
  34 00:51 <Mithrandir> Skif: it'll follow
  35 00:52 <Skif> Mithrandir: not if nobody else follows us, in that regard and I'm fairly sure they won't.
  36 00:52 <Mithrandir> Skif: it's how gcc does cross compiles today.
  37 -:- bdale [] has joined #debian-devel
  38 00:52 <Skif> Mithrandir: I'm not convinced cross compiles are a case worth optimizing for.
  39 00:52 <Mithrandir> Skif: you already have a bunch of systems out there with /usr/$arch-linux
  40 -:- taggart [] has joined #debian-devel
  41 00:52 <DanielS> RHAT does /usr/$arch-linux, IIRC.
  42 00:53 <Mithrandir> taggart: care to read ?
  43 00:53 <DanielS> It did at one point, at least.
  44 00:53 <Mithrandir> bdale: does seem according to what we discussed?
  45 00:53 <Mithrandir> DanielS: ISTR, yes.
  46 00:53 <DanielS> afk
  47 00:53 <Skif> DanielS: not for RHEL AS{2.1,3} AFAIK
  48 00:53 <Snow-Man> Mithrandir: You don't refer to /lib, will it be considered 'historical' as well?
  49 00:53 * GyrosGeier/#debian-devel has /usr/i586-mingw32msvc from the mingw32 package.
  50 00:54 <Kamion> I'd have thought /lib couldn't disappear, /lib/ is part of the ABI
  51 00:54 <bdale> Mithrandir: looking
  52 00:54 <Mithrandir> Snow-Man: we'll have /lib/$(gcc -dumpmachine)
  53 00:54 <Mithrandir> bdale: thanks
  54 00:54 <Snow-Man> Kamion: That can be changed, and can be kept around using symlinks until it can be removed entirely.
  55 00:54 <Mithrandir> it'll require minor changes to gcc's spec file.
  56 00:54 <Snow-Man> Mithrandir: Interesting.
  57 00:55 <Snow-Man> Mithrandir: That's for everything then?  i386 and amd64 and everyone?
  58 00:55 <doogie> oh, and let's not use -dumpmachine, k?
  59 00:55 <doogie> that's not extensible.
  60 00:55 <GyrosGeier> mithrandir, /usr/$(gcc -dumpmachine)/lib sounds better to me. What is the reasoning behind /lib/$(gcc -dumpmachine) ?
  61 00:55 <Snow-Man> Mithrandir: So as things get recompiled their files will move to /lib/$(gcc -dumpmachine)?
  62 00:56 <Snow-Man> GyrosGeier: Erm, you have to do something for /lib and something for /usr/lib.
  63 00:56 <Mithrandir> GyrosGeier: huh?  you don't have /include, do you?
  64 00:56 <GyrosGeier> mithrandir, /$(gcc -dumpmachine)/lib, then.
  65 00:56 <Mithrandir> Snow-Man: yes, it's for all.
  66 00:56 <Snow-Man> GyrosGeier: That's just nasty. :)
  67 00:56 <Snow-Man> Mithrandir: Hrm.
  68 00:56 <Mithrandir> GyrosGeier: that'd cause you to have many top-level dirs, ugly.
  69 00:56 <doogie> Mithrandir: this will require changes to autoconf/libtool/automake, so the proposal in invalid because of just that.
  70 00:56 <Mithrandir> GyrosGeier: and they'd all have just lib in them.
  71 00:57 <doogie> and all such programs that use them.
  72 00:57 <Snow-Man> Mithrandir: That will be interesting.  We'll need to have symlinks for the linker.
  73 00:57 <Keybuk> libtool already supports it
  74 00:57 <Snow-Man> doogie: Oh, hush.
  75 00:57 <Mithrandir> doogie: the proposal is _invalid_ because it requires changes?
  76 00:57 <GyrosGeier> mithrandir, in that dir there is bin, lib and include
  77 00:57 <Mithrandir> Snow-Man: yes.
  78 00:57 <doogie> Mithrandir: because it requires something too low-level, which has no hope of being implemented.
  79 00:57 <Snow-Man> Mithrandir: Think we'll be able to just ln -s /lib /lib64?
  80 00:57 <Mithrandir> GyrosGeier: you want to have /$(gcc -dumpmachine)/include ?
  81 00:57 <Mithrandir> if so, you're on crack.
  82 00:57 <GyrosGeier> mithrandir, nope.
  83 00:58 <Snow-Man> Mithrandir: With the right symlinks in /lib it should work, and be binary compatible with other distros.
  84 00:58 <Mithrandir> doogie: the bits are already there, it's just a matter of work to get it working.
  85 00:58 <Snow-Man> Though may still break some shitty commercial apps that use rpath and nasty shit.
  86 00:58 <doogie> Mithrandir: you jumped into a solution too quick in your url.  please explain(in heavy detail) the issues.
  87 00:58 <Keybuk> all the low-level support is largely there because this is how GNU supports cross-compiling and multi-homing anyway :)
  88 00:58 <Snow-Man> From what I've been told anyway, no one has actually showed one to me.
  89 00:58 <p2-mate> Mithrandir: what about /usr/lib, /usr/include ?
  90 00:58 <doogie> you haven't fully described the problem set, in only a single paragraph.
  91 00:59 <doogie> you then have a much more complex solution.
  92 00:59 <Mithrandir> p2-mate: they'll go away.
  93 00:59 <Mithrandir> hopefully.
  94 00:59 <doogie> I want the solution to be simpler than the problem set, not more complex.
  95 00:59 * Keybuk/#debian-devel remains unconvinced that they'll ever truly go away
  96 00:59 <Snow-Man> Mithrandir: It doesn't seem too bad.
  97 00:59 <Snow-Man> Mithrandir: I'll think about it more.
  98 00:59 <Mithrandir> Keybuk: well, if not, they'll stay and be hysterical artifacts.
  99 01:00 <p2-mate> Mithrandir: what happens to /usr/include ?
 100 01:00 <Snow-Man> hysterical?  haha.
 101 01:00 <Kamion> they'll stay for non-multiarch stuff I'd've thunk
 102 01:00 <GyrosGeier> mithrandir, the point is that having that dir in $(prefix) is sort of a standard.
 103 01:00 <doogie> oh, and why are we calling it amd64?
 104 01:00 <Kamion> plenty of that'll still be around
 105 01:00 <taggart> Mithrandir: skimmed, it looks like it matches my proposal, right?
 106 01:00 <Mithrandir> taggart: I think so.
 107 01:00 <p2-mate> Mithrandir: and /bin will move to /bin/$(gcc -dumpmachine) as well ?
 108 01:00 <Mithrandir> bin will not move.
 109 01:00 <Snow-Man> No, just libraries will be affected.
 110 01:00 <Mithrandir> p2-mate: I hope /usr/include goes away, eventually, but it won't do any harm.
 111 01:01 <Mithrandir> if it stays.
 112 01:01 <taggart> Mithrandir: I need to spend some time updating that page and shopping it around
 113 01:01 <p2-mate> Mithrandir: how can I have multiple binaries with the same name and a different arch then ?
 114 01:01 <taggart> p2-mate: no
 115 01:02 <taggart> here's my multi-arch proposal btw -
 116 01:02 <GyrosGeier> mithrandir, /usr/i586-mingw32msvc/bin contains the cross-compile binaries, and this is the "standard" path the cross-compiler will look in. I think it makes some sense to keep that stuff together.
 117 01:02 <Kamion> GyrosGeier: but $PATH ...
 118 01:03 <GyrosGeier> Kamion, the basename is the same
 119 01:03 <GyrosGeier> Kamion, /usr/i586-mingw32msvc/bin/ar, for example.
 120 01:03 <p2-mate> taggart: arm does not support running mixed endian binaries
 121 01:03 <Keybuk> the fact ia64 does *scares* me
 122 01:03 <Kamion> not exactly helpful if it's not in users' paths though; hence i386-linux-ar and such
 123 01:04 <Kamion> but that's pretty compilerish and not very friendly
 124 01:04 <GyrosGeier> Kamion, it doesn't need to be, as long as the compiler finds it.
 125 01:04 <Keybuk> I swear there's a whole world of "I put this int down a pipe because I knew it had to be the same endianness on the other end" waiting for that
 126 01:04 <Mithrandir> Keybuk: we'll find out
 127 01:04 <doogie> Mithrandir's proposal doesn't handle optimization flags
 128 01:04 <taggart> p2-mate: someone told me it can be either
 129 01:04 <Mithrandir> doogie: what kind of optimization flags?
 130 01:04 <doogie> Mithrandir: sse/3dnow
 131 01:04 <Kamion> GyrosGeier: maybe I was reading the wrong thing but some people were talking about more than just compilers
 132 01:04 <doogie> for example
 133 01:05 <taggart> p2-mate: but I guess the platform just picks one or the other
 134 01:05 <Kamion> (I'm not sure that's a problem we need to solve, though)
 135 01:05 <p2-mate> taggart: arm cores can be either, but it's defined by the hardware
 136 01:05 <doogie> my arm core is made up of bone
 137 01:05 <Mithrandir> doogie: why should it?  if it used to go into /usr/lib/sse, it'll go into /usr/i386-linux/lib/sse
 138 01:05 <Mithrandir> that's obvious.
 139 01:05 <GyrosGeier> Kamion, my point is that there is no need to have different dirs for the cross compilers and the runtime.
 140 01:05 <taggart> doogie: no, marrow dude
 141 01:06 <doogie> taggart: no, the bone's core is marrow
 142 01:06 <p2-mate> taggart: there is no big endian arm in debian anyway now afaik
 143 01:06 <Mithrandir> GyrosGeier: bin is /usr/bin, /bin, as usual.
 144 01:06 <GyrosGeier> Kamion, especially since the dirs for the compilers are an industry standard, if you can call something the GNU people did as such.
 145 01:06 <Kamion> GyrosGeier: allow me to bow out here, I don't much care about cross-compilers (since they already basically work)
 146 01:06 <taggart> p2-mate: that proposal is for the lsb/fhs, not just debian
 147 01:06 <doogie> Mithrandir: what happens when multiple optimizations are enabled?
 148 01:06 <p2-mate> taggart: it's a bug it's not in :)
 149 01:07 <Mithrandir> doogie: how is that handled today?
 150 01:07 <p2-mate> taggart: multiple binaries do make sense
 151 01:07 <taggart> p2-mate: fine argue with the ftp admins to add it :)
 152 01:07 <p2-mate> taggart: multiple binaries with the same name :)
 153 01:07 <doogie> it's not.
 154 01:07 <Skif> I can think of at least one good reason to have multi-arch binaries as well: what if you need to debug 32-bit emulation on a 64-bit platform, and you want to have both binaries easily available for comparison?
 155 01:07 <taggart> p2-mate: yeah the more I think about it the more I think we'll need this for bin too :(
 156 01:07 <Mithrandir> Skif: /usr/local
 157 01:07 <Mithrandir> or a chroot
 158 01:08 <Kamion> Skif: binaries, sure, but dpkg -x can unpack them from other arches
 159 01:08 <Skif> Mithrandir: I said "easily available"
 160 01:08 <Mithrandir> Skif: apt-get install debootstrap
 161 01:08 <doogie> taggart's is a much better written document.
 162 01:08 <Kamion> dpkg -x is pretty easy
 163 01:08 <Mithrandir> doogie: it can be handled by the linker, to some extent.  I'm not sure we want to solve all the world's problems.
 164 01:08 <azeem> Skif: debuggin 32bit emulation is not the common case we should optimize for, I guess
 165 01:08 <GyrosGeier> mithrandir, yep. so there will be /{,usr/{,local/}}$(arch)/{bin,lib,include}/.
 166 01:08 <Mithrandir> GyrosGeier: s/bin,//
 167 01:08 <doogie> mithrandir's doesn't tell me what the real problem is, then goes on to try and talk about implementation.
 168 01:09 <Skif> azeem: I'm sure there are others-- maybe ASPs who wish to provide customers easy access to both at the same time
 169 01:09 <doogie> taggart's describes the problem very well, but doesn't actually say how it will be imlemented.
 170 01:09 <Mithrandir> doogie: read the two first sentences of what I've written
 171 01:10 <GyrosGeier> mithrandir, bin will be there, except if you convince the GNU people.
 172 01:10 <Mithrandir> GyrosGeier: I don't need to convince any gnu people.  Debian's not GNU, Debian's Debian.
 173 01:10 <GyrosGeier> mithrandir, but Debian should provide a familiar environment.
 174 01:10 <Keybuk> aww, but I wanna be an unconvinced GNU person *stamps foot*
 175 01:11 <Mithrandir> Keybuk: you don't count.  You've helped out writing the proposal :)
 176 01:11 <doogie> side question: will a single binary be able to link to 2 arch libs at the *same* time?
 177 01:11 <p2-mate> taggart: LE ppc is not even supported by linux
 178 01:11 <asuffield> you might as well do it for bin too
 179 01:11 <Mithrandir> GyrosGeier: yes, and having binaries in /usr/bin and not some random other location is familiar.
 180 01:11 <asuffield> and then somebody can hack the kernel to do the same thing for exec() that glibc does for dlopen()
 181 01:12 <asuffield> (try mutating the path based on available hardware capabilities)
 182 01:12 <asuffield> ...what am I thinking? do it in glibc
 183 01:12 <asuffield> all the code's already there. paste and go
 184 01:13 <doogie> then you'd be tied to glibc. :)
 185 01:13 <doogie> poor netbsd people.
 186 01:13 <taggart> p2-mate: this proposal is meant to cover all possible cases, not just those in existance
 187 01:14 <asuffield> doogie: they don't get any of this stuff anyway
 188 01:14 <GyrosGeier> mithrandir, the binaries in /usr/bin are those the user sees. The ones in the arch-specific dirs are the cross-compiler binaries. No problem with that. The remaining issue is whether the libs will go into /lib/$(arch) or into /$(arch)/lib (prefix omitted), where I think the latter is better since everything multi-arch would be confined to one directory per arch and prefix; your initial proposal made the $(arch) dirs under /lib, t
 189 01:14 <asuffield> doogie: that's just a variation on "If you use a less featureful libc then you will have less features"
 190 01:14 <GyrosGeier> mithrandir, issue.
 191 01:15 <doogie> I like $prefix/$arch-id/{dir1,dir2}
 192 01:15 <Mithrandir> GyrosGeier: you were cut off at: "$(arch) dirs under /lib, t"
 193 01:15 <taggart> doogie: my doc lists an implementation, did you see that part?
 194 01:15 <p2-mate> taggart: also those who will never be done
 195 01:15 <doogie> you could then nfsmount/share $prefix/$arch-id/
 196 01:16 <GyrosGeier> mithrandir, thatï's the whole issue.
 197 01:16 <GyrosGeier> mithrandir, that was all.
 198 01:16 <doogie> taggart: you describe an implementation; mithrandirs talks about how one goes and modifies dpkg.
 199 01:16 <asuffield> p2-mate: people have a habit of doing things that will never be done
 200 01:16 <doogie> $prefix/$arch/{lib,include} is my vote.
 201 01:16 <p2-mate> asuffield: that's why we don't have a LE PPC port
 202 01:17 <doogie> note, this is how libc5 libs are dealt with.
 203 01:17 <asuffield> p2-mate: remember that powerpc is not a chip, it's a vague description. it's entirely possible that future hardware changes will change things
 204 01:17 <taggart> doogie: oh for debian yeah, mine gives the general runtime implementation
 205 01:17 <doogie> er, no, that dir isn't libc5, or hmm.
 206 01:17 <GyrosGeier> sec, trouble with the IRC client.
 207 01:17 <Mithrandir> GyrosGeier: you misunderstood.  you'll have /lib/$arch and /usr/$arch/lib.
 208 01:17 <asuffield> there's already three completely unrelated powerpc chips
 209 01:18 <doogie> Mithrandir: /$arch/lib and /usr/$arch/lib
 210 01:18 <asuffield> series of chips, even
 211 01:18 <p2-mate> which are all big endian
 212 01:18 <Mithrandir> doogie: that's silly.
 213 01:18 <doogie> let's not change the ordering based on whether $prefix = /
 214 01:18 <asuffield> p2-mate: coincidental. you don't know that the next six will be
 215 01:18 <doogie> makes the code more complex
 216 01:18 <Mithrandir> doogie: we're not changing it based on that.
 217 01:18 <Mithrandir> if you think we're doing that, you obviously haven't thought about why we are doing it.
 218 01:18 <p2-mate> asuffield: that's not a coincidence at all
 219 -:- Kamion [] has left #debian-devel []
 220 01:19 <Mithrandir> and the code would be more complex by doing /$arch/lib/ than /lib/$arch, since the latter is already supported
 221 01:20 <calc> taggart: i didn't notice if you mentioned that headers can currently be arch dependent
 222 01:20 <doogie> Mithrandir: sharing the files is very important.
 223 01:20 <calc> taggart: and how to resolve that
 224 01:20 <doogie> and it's much harder with /lib/$arch and /include/$arch
 225 01:20 <Mithrandir> you don't want /include
 226 01:20 <taggart> calc: I don't, but I've thought about it
 227 01:21 * calc/#debian-devel personally thinks the long term goal for that is to have separate arch independent include dir and an arch dep dir
 228 01:21 <taggart> calc: and ideally they'd be unified and ifdef'd
 229 01:21 <taggart> yeah arch dependent should be in some asm dir right?
 230 01:21 <calc> taggart: how do you resolve issues where the arch dependent stuff is generated at build time?
 231 01:21 <asuffield> calc: by applying a club to the author
 232 01:22 <calc> well some arch dependent stuff now isn't just asm
 233 01:22 <calc> its eg for int sizes, etc
 234 01:22 <asuffield> calc: it is not exactly complicated to write a header that doesn't depend on those things
 235 01:22 <asuffield> use int instead of char[4], sizeof(int) instead of 4, etc
 236 01:24 <Keybuk> asuffield: where do you put the header that defines uint64_t ? :p
 237 01:24 <asuffield> Keybuk: it's defined in terms of __moo_bar__uint64_t, which comes from include/asm
 238 01:24 <asuffield> glibc's already arch-indep for stuff like that
 239 01:24 <Keybuk> what about uid_t ?
 240 01:24 <asuffield> that's from asm/ as well
 241 01:25 <calc> and how do you deal with making it work on non glibc using systems? ;)
 242 01:25 <asuffield> calc: you don't
 243 01:25 <calc> so it is still a problem!
 244 01:25 <calc> only linux uses glibc
 245 01:25 <asuffield> calc: yes. somebody else's problem. specifically their problem is that their libc is shit
 246 01:25 <asuffield> fixing their libc is not our problem
 247 01:25 <calc> go back to your little cave ;)
 248 01:26 <calc> or ivory tower, ymmv ;)
 249 01:26 <Keybuk> dungeon of hell?
 250 01:26 <vorlon> asuffield: yes, we are impervious to your silly real-world production environments!
 251 01:26 <Mithrandir> ivory cave?
 252 01:26 <Keybuk> shed of doom?
 253 01:26 <calc> people want their code to work on more than just linux, so solving the arch dependent header problems is a _glibc/linux_ problem
 254 01:26 <asuffield> vorlon: why are you even expecting this to work there?
 255 01:27 <asuffield> start from "let's add a feature to Debian", not "let's add a feature to every unix in the world"
 256 01:27 <asuffield> otherwise you'll get nowhere
 257 01:27 <calc> asuffield: thats what you tried to say they should do
 258 01:27 <asuffield> calc: eh?
 259 01:27 <calc> asuffield: 18:30  asuffield calc: yes. somebody else's problem. specifically their
 260 01:27 <calc>                    problem is that their libc is shit
 261 01:27 <calc> you said that everyone else in the world should fix their libc
 262 01:27 <doogie> Mithrandir: you don't need any Multi-Arch flag.
 263 01:27 <Mithrandir> doogie: oh?
 264 01:28 <calc> when its linux that needs to fix their header stuff to deal with arch dependent headers :)
 265 01:28 <asuffield> calc: yes. that means *not us*. if *they* want to support this multi-arch stuff, then *they* can implement it
 266 01:28 <doogie> Mithrandir: just set the Architecture like normal in any deb; then, each host system will maintain a list of compatible arches allowed for installation.
 267 01:28 <doogie> Mithrandir: you still require moving arch-dep files into arch-dep dirs, tho.
 268 01:28 <calc> asuffield: debian wants to support multi-arch the others could care less
 269 01:28 <Mithrandir> doogie: that doesn't allow you to transition gracefully.
 270 01:28 <asuffield> calc: so why are you worrying about the fact that they won't support it?
 271 01:28 <Keybuk> calc: in fine tradition, they'll care the second we support it, borrow our implementation and claim it was their idea all along :p
 272 01:29 <doogie> Mithrandir: when installing a non-default-arch deb, dpkg will switch into your special mode.
 273 01:29 * calc/#debian-devel got confused now
 274 01:29 <doogie> normal file overlap resolution will still apply, which solves one problem.
 275 01:29 <asuffield> <calc> and how do you deal with making it work on non glibc using systems? ;)
 276 01:29 <asuffield> <asuffield> calc: you don't
 277 01:29 <asuffield> calc: this isn't complicated :P
 278 01:29 * calc/#debian-devel thinks he said we need to long term make separate include indep and include arch dirs to resolve this problem, asuffield said that it should all be written upsteam, etc 
 279 01:30 <Mithrandir> doogie: you can read "Multi-Arch: yes" as "This-Does-Not-Conflict-With-Packages-With-Same-Name-But-Different-Architecture: true"
 280 -:- SignOff Keybuk: #debian-devel ("Leaving")
 281 01:30 <asuffield> calc: I doubt you'll find many upstreams that don't already do it properly. we can fix the ones that don't, at least on Debian
 282 01:30 <calc> hmm ok
 283 01:31 * calc/#debian-devel thought it was fairly common
 284 01:31 <calc> esp since autotools makes it easy to do
 285 01:31 <asuffield> how often do you see somebody installing an autogenerated header file?
 286 01:31 <doogie> Mithrandir: multi-arch is a bad name, but your other choice is too long.  how about ...
 287 01:31 * doogie/#debian-devel thinks
 288 01:31 <calc> asuffield: actually often in my case
 289 01:31 <calc> i don't know if kde does it but ogg vorbis does in all their libs
 290 01:31 <doogie> Parallel something?
 291 01:32 <Mithrandir> doogie: "Implicit-Arch-Conflict: no"?
 292 01:32 <asuffield> calc: and how much of that stuff is arch-dep?
 293 01:32 <doogie> Mithrandir: no arch in the name.
 294 01:32 <asuffield> that's *one* case, and if it actually is a problem, I bet it's easy to fix
 295 01:32 <calc> the stuff generated is
 296 01:32 <calc> its size of vars, etc
 297 01:32 <taggart> Mithrandir: if we solve the bin conflict could we make it so any existing package could be installed on an arch that supports it? we still have things like /usr/share (non lib/bin stuff in /usr and /var)
 298 01:33 <taggart> it would be so cool to just be able to do that
 299 01:33 <Mithrandir> taggart: I guess a binary could use alternatives to manage alternatives to itself, somehow.
 300 01:33 <bob2> Parallel-Arch-Install:?
 301 01:33 <taggart> especially for the emulation cases too
 302 01:33 <calc> yea it would be nice to be able to completely install all/almost all packages and use qemu, for example
 303 01:33 <doogie> no one answered my question from before
 304 01:33 <doogie> doogie side question: will a single binary be able to link to 2 arch libs at the *same* time?
 305 01:33 <asuffield> typedef int16_t ogg_int16_t;
 306 01:33 <asuffield> typedef u_int16_t ogg_uint16_t;
 307 01:33 <asuffield> typedef int32_t ogg_int32_t;
 308 01:33 <asuffield> typedef u_int32_t ogg_uint32_t;
 309 01:33 <asuffield> typedef int64_t ogg_int64_t;
 310 01:33 <asuffield> well that's fucking useless
 311 01:34 <asuffield> calc: this isn't arch-dep, anyway
 312 01:34 <bob2> haha
 313 01:34 <calc> asuffield: which are different on other OS'es etc
 314 01:34 <taggart> doogie: interesting question
 315 01:34 <doogie> probably depends on the target system.
 316 01:34 <taggart> doogie: I think ld may support that in some cases already
 317 01:34 <asuffield> calc: I don't think we need to worry about platforms that do not implement C
 318 01:34 <bob2> doogie: that sounds like a horrific can of worms with big teeth.
 319 01:35 <asuffield> calc: it's not going to be our problem
 320 01:35 <doogie> mark the executable pages as being native, or emulated
 321 01:35 <Mithrandir> doogie: you don't want to link to both amd64 and i386 libs, no.  not unless you thunk or something.
 322 01:35 <doogie> could valgrind be used as in i386 interpeter?
 323 01:35 <asuffield> Mithrandir: could do multiarch binaries, but I think it's a bad idea
 324 01:35 <bob2> doogie: qemu could.
 325 01:36 <doogie> remove the memory stuff, and it's mostly done.
 326 01:36 <asuffield> better to do bin/i386-linux/foo and teach glibc how to exec() it
 327 01:36 <doogie> asuffield: what about tab completion?
 328 01:36 <doogie> fo<tab>
 329 01:36 * GyrosGeier/#debian-devel thinks multiarch binaries are a good thing. AmigaAmp for example has its GUI running on m68k and its decoder running on powerpc, if you want.
 330 01:37 <asuffield> doogie: symlink forest
 331 01:37 <vorlon> asuffield: /usr/include/zconf.h is my favorite du jour.
 332 01:37 <doogie> GyrosGeier: simpler to use multiple processes, and pipes/shared memory/ipc
 333 01:37 <p2-mate> GyrosGeier: and then migrate a process from PPC to m68k ? :)
 334 01:37 <asuffield> doogie: /usr/bin/foo should do *something* useful, even if glibc picks a different binary most of the time
 335 01:37 <taggart> doogie: and you'd probably have separate paths and decide which it searchs first
 336 01:38 <asuffield> vorlon: this header appears to be arch-indep already
 337 01:38 <vorlon> asuffield: especially the part where z_off_t is #defined to off_t, that's real keen.
 338 01:38 <taggart> so I really think whatever solution we come up with for debian will allow for immediately installing all the lib packages from one arch on another
 339 01:38 <asuffield> vorlon: yeah, it's stupid and broken, but it doesn't suffer from this particular problem :P
 340 01:39 <taggart> well wait
 341 01:39 <taggart> maybe we require them to rebuild with the new lib path
 342 01:40 <taggart> but we're going to need a way to deal with stuff like /usr/share/doc for every package
 343 01:40 <asuffield> taggart: path exclusion in dpkg would be the simple one
 344 01:40 <taggart>  /usr/share/doc/i386-linux ?
 345 01:40 * taggart/#debian-devel runs :)
 346 01:40 <Mithrandir> asuffield: oh?  how would that solve it?
 347 01:41 <asuffield> Mithrandir: "Don't install anything from /usr/share unless it's from an i386 package"
 348 01:41 <asuffield> imperfect but pretty close
 349 01:41 <p2-mate> taggart: put all docs in a separate package ?
 350 01:41 <doogie> move all /usr/share into a separate deb.
 351 01:41 <taggart> asuffield: yeah the weird problem is when you have different versions of two lib packages installed, which docs win?
 352 01:41 <Mithrandir> asuffield: that would suck royally, imho.
 353 01:41 <asuffield> Mithrandir: why?
 354 01:41 <taggart> p2-mate: well all packages have /usr/share/doc today if only for copyright, changelog, etc
 355 01:42 <asuffield> taggart: whichever one you asked for
 356 01:42 <doogie> libfoo:i386 depends libfoo-doc; libfoo:x86-64 depends libfoo-doc; libfoo-doc contains /usr/share/doc/libfoo, and /usr/share/doc/libfoo-doc -- libfoo
 357 01:42 <taggart> asuffield: s/for/for most recently/ ?
 358 01:42 <doogie> this will work fine for policy, and not have any conflicts when installing both libfoo:i386 and libfoo:x86-64 on x86-64
 359 01:43 <doogie> and requires no changes in dpkg(which is very good)
 360 01:43 <p2-mate> taggart: yes, so ?
 361 01:43 <asuffield> taggart: that's purely an interface issue. but that is what you expect from dpkg, so it would make sense
 362 01:43 <doogie> taggart: all packages do not have a copyright file inside them.
 363 01:43 <azeem> doogie: except it would ramp up the package count by a lot, no (which is not good)
 364 01:43 <taggart> p2-mate: oh I see what you're saying
 365 01:43 <doogie> azeem: and reduce mirror size.
 366 01:43 <p2-mate> doogie: why would you need the dependency ?
 367 01:44 <doogie> of course, libfoo-doc is not really a good name.
 368 01:44 <doogie> p2-mate: policy requires that installing libfoo make /usr/share/doc/libfoo/copyright available.
 369 01:44 <Skif> package exclusion would have other nice side benefits, like removing the need for localepurge
 370 01:44 <p2-mate> doogie: change policy then
 371 01:44 <taggart> doogie: yeah I guess that's still not *required* by the deb format, but isn't it by policy for packages in the archive?
 372 01:44 <doogie> libfoo-doc should contains docs on how to use libfoo; which may or not contains libfoo's copyright.
 373 01:45 <p2-mate> I rather not have a million copyright files on my 8MB flash system :P
 374 01:45 <doogie> taggart: a package may not contain a copyright file, if one of it's dependants contains it, after installing the dependant it is available as /usr/share/doc/$pkg/copyright
 375 01:45 <asuffield> I'm thinking of something along the lines of a config file in /etc/dpkg/ that says things like "exclude amd64 /usr/share" "exclude libsuck* i386 /usr/share" "include libsuck* amd64 /usr/share"
 376 01:45 <asuffield> (for fuck's sake don't use that config file format)
 377 01:46 <asuffield> that first one should have been "exclude * amd64 /usr/share"
 378 01:46 <taggart> so hp-ux's package manager has these multi-level packages and binaries, libs, and docs are split into subpackages. that would make it easier to exclude
 379 01:46 <doogie> asuffield: so if one installs i386 only version of a lib, and not the x86-64 version, then they have no copyright file.
 380 01:46 <asuffield> doogie: their fault. you get the same effect if you install the package now and delete the copyright file
 381 01:46 <doogie> I like my version more.
 382 01:46 <Skif> taggart: didn't elmo recently say each new packages requires about 1k in the Packages file?
 383 01:47 <Mithrandir> taggart: it would be nice if we didn't have to rip dpkg wholly apart
 384 01:47 <doogie> my version also requires no changes to dpkg.
 385 01:47 <doogie> other than same-name/different-arch thing.
 386 01:48 <asuffield> doogie: be creative. "prefer * i386 /usr/share", which means that if you install an i386 package and something else, the other one gets its files in /usr/share excluded
 387 01:48 <asuffield> doogie: bah, we've been after this change to dpkg for years :P
 388 01:48 <Skif> taggart: IIRC (it's been a while) the hpux package would be more akin to a debian task, so in that sense, we already have the subpackages, and the overall package is less useful to us
 389 01:49 <taggart> while we're at it let's unify package formats too :)
 390 01:49 <doogie> which shouldn't be too hard to do.
 391 01:49 <taggart> (and solve world hunger etc)
 392 01:49 <Mithrandir> doogie: what provides /usr/share/doc/libfoo, then?
 393 01:49 <doogie> Mithrandir: libfoo-copyright
 394 01:49 <doogie> that provides *both* /usr/share/doc/libfoo and libfoo-copyright; one can be by way of symlink
 395 01:49 <doogie> currently, libfoo is generally provided by libfoo.deb, and is a symlink to the other package.
 396 01:49 <doogie> but policy just says that when a package is installed, and all it's dependencies installed, that the copyright exists at /usr/share/doc/$pkg/copyright
 397 01:49 <taggart> Skif: yeah, Packages files are not as scalable as we'd like. maybe that problem should be solved too
 398 01:49 <doogie> taggart: I'm working on that problem.
 399 01:49 <doogie> I need to see the deltas for Packages(and Sources), so I can see how incremental stuff would work.
 400 01:50 <taggart> Skif: yeah hp-ux has Depots, Bundles, Products, Filesets, and Files
 401 01:50 <doogie> also, remember, one of debian's features is that you can extract a deb using normal unix tools.
 402 01:50 <joshk> YARRGH
 403 01:50 <doogie> having to special case some dir means you can't do that anymore.
 404 01:50 <joshk> don't remind me of depots
 405 01:51 <asuffield> taggart: hp-ux also has users that universally loathe it :P
 406 01:51 <taggart> Skif: the Fileset level was the foo-bin, foo-man, foo-lib level
 407 01:51 <taggart> asuffield: yep
 408 01:52 <Skif> taggart: ah, now it all comes back to me.  Unfortunately. :)  Anyway, one of Debian's big strengths is our micropackaging, so adding extra layers in there would be counterproductive.
 409 01:52 <taggart> yeah
 410 01:52 <Skif> Although if you're trying to force a rewrite of dpkg, that might not be a bad way to go about it  :)
 411 01:53 <taggart> but making bin package only contain stuff that goes in bin dirs, lib to lib, doc to doc, etc. might be good
 412 01:53 <seeS> vorlon: thanks for debugging that php snmp problem, a rather strange one
 413 01:54 <taggart> maybe it means every package gets a -common package
 414 01:54 <Skif> ack, package explosion :(
 415 01:54 <taggart> that would only mean about another 6-8k packages right? :)
 416 01:54 * Skif/#debian-devel agrees w/doogie that installing a libfoo package should at least give you /usr/share/doc/libfoo/copyright
 417 01:55 <doogie> using depends to that works nicely, and without changes to dpkg.
 418 01:55 <doogie> +do
 419 01:55 <doogie> Skif: it's mentioned in policy; I'm just too lazy to look it up right now
 420 01:55 <Skif> taggart: yeah, cheap at half the price :)
 421 01:55 <taggart> Skif: s/installing/installing with ar and tar and gunzip/ ?
 422 01:55 <doogie> taggart: we never said that installing with unix tools means you can't follow the depends.
 423 01:56 <taggart> normal installing would have the right -common dependencies
 424 01:56 <doogie> you still have to read the meta data in control.tar.gz
 425 01:56 <taggart> doogie: good point
 426 01:56 <doogie> you can just get *at* the meta-data with unix tools.
 427 01:57 <taggart> so if you're installing two different version of a lib package the -common file with the higher version should win, but not cause a conflict
 428 01:57 <taggart> and as long as things depend on their version of the -common file or greater that should work right?
 429 01:58 <Skif> taggart: are you referring to libfoo/libfoo2 'different versions'?  In that case, normal dpkg dependencies should work.
 430 01:58 <taggart> Skif: no libfoo:i386:1.0 and libfoo:x86_64:1.2
 431 01:58 <Skif> If you mean libfoo1-1.3-1 on i386 and libfoo1-1.3-4 on x86_64, that shouldn't be allowed.
 432 01:59 <taggart> why not? people will want to do that?
 433 01:59 <taggart> s/at\?/at/
 434 01:59 <doogie> if dpkg had virtual provides, this would be easy too
 435 01:59 <Skif> why would they want to?  Why wouldn't you want the same versions on all arches?
 436 01:59 <doogie> libfoo-common conflicts: libfoo (<< $current_version)
 437 01:59 <doogie> actually, virtual provides *may* not be required ehre.
 438 02:00 <taggart> you have application foo:i386 that needs one version and app bar:ia64 that needs another version
 439 02:00 <doogie> when checking conflicts, don't consider multi-arch stuff; libfoo:i386 and libfoo:x86-64 would both have to upgraded in this case.
 440 02:00 <Skif> then do what mithrandir suggested and make a chroot for one of them
 441 02:01 <maswan> taggart: .. optimize for the common case?
 442 02:01 <doogie> taggart: in that case the whole upgrade stops, and you wait until all apps work.
 443 02:01 <doogie> that's what apt will do anyways.
 444 02:01 <Skif> It seems like a fairly pathological case, anyhow.
 445 02:01 <doogie> if upgrading to a new libfoo causes app-bar to fail, then libfoo needs a new soname(ignoring regular simple bugs)
 446 02:01 * taggart/#debian-devel thinks it will occur quite often
 447 02:02 <maswan> Skif: well, it might happen now and then when following unstable, then you wait for tomorrow for it to be fixed.
 448 02:02 <Skif> maswan: sure, but that's why we call it 'unstable' :)
 449 02:02 <taggart> I think EDA folks are going to be the big users using these 32/64 boxes and they often have a ton of tools
 450 02:03 <taggart> some of which are ported to 64bit and some that aren't
 451 02:03 <maswan> EDA?
 452 02:03 <doogie> you know, why are binary-all Package stanzas in binary-i386/Packages?
 453 02:03 <doogie> why not have a binary-all/Packages?
 454 02:03 <taggart> electronic design automation
 455 02:03 <maswan> ah
 456 02:03 <Skif> taggart: but you also have app1 needs libfoo-1.0 and app2 needs libfoo-1.2 even on the same arch, right now
 457 02:03 <doogie> that would solve the package-splitting-adding-1k-to-Packages problem.
 458 02:03 * Skif/#debian-devel has a friend in EDA, and they don't really have a big problem with that sort of thing.
 459 02:03 <taggart> chip designers like 64bit for the address space
 460 02:03 <maswan> Well, seems like a special case of the HPC world that I'm seeing a bunch of.
 461 02:03 <taggart> 64bit computing was invented for them
 462 02:03 <taggart> well them and databases I guess
 463 02:04 <doogie> binary-all/Packages solves an existing problem today, and makes it easier later on.
 464 02:04 <taggart> but them first :)
 465 02:04 <maswan> taggart: I think I saw some press release by AMD shortly after the Opteron release saying "finally, we are using our own chips everywhere"
 466 02:05 <taggart> doogie: good fucking question on the binary-all thing.
 467 02:05 <doogie> currently, binary-all/.../*.deb is included in *every* binary-$arch/Packages
 468 02:05 <doogie> which seems very stupid to me.
 469 02:05 <taggart> maswan: yeah I think they were buying hppa boxes before that :)
 470 02:06 <maswan> taggart: :)
 471 02:07 <doogie> taggart: probably historical reasons, and no one ever made apt do it.
 472 02:10 <doogie> anyways, here's the steps.
 473 02:10 <doogie> fix apt(in unstable after sarge), to fetch binary-all/{Packages,Source}
 474 02:10 <doogie> fix dinstall to generate those, and no longer include the stanzas in binary-$arch
 475 02:11 <doogie> fix $prefix/usr/$arch/{lib,include,..} paths
 476 02:11 <doogie> split libfoo into libfoo and libfoo-common, the latter exists in -all
 477 02:11 <doogie> then, it's a small change in apt and dpkg to support installing multiple libfoo at once
 478 02:12 <taggart> so what do people think of the -common idea?
 479 02:12 * maswan/#debian-devel thinks it is a good idea
 480 02:12 <doogie> it doesn't have to be -common; the maintainer can use whatever he/she/it wants
 481 02:12 <taggart> doogie: I think it should be consistant
 482 02:13 <doogie> taggart: doesn't need to be; re: -doc and -docs
 483 02:13 <maswan> taggart: yeah, just like -doc and -dev
 484 02:13 <doogie> -doc is not standard
 485 02:13 <taggart> doogie: -doc and -docs sucks
 486 02:13 <maswan> doogie: probably should be though. at least a strong recommendation.
 487 02:13 * taggart/#debian-devel filed a bunch of bugs on those a while back IHRC
 488 02:13 <doogie> making it work doesn't require the name to be anything in particular; however, policy can decide to enforce the naming.
 489 02:14 <doogie> I'm just listing what is required.
 490 02:14 <doogie> anyways, going home, back later
 491 02:14 <maswan> doogie: Ah, ok.
 492 02:14 <doogie> someone want to type this up?
 493 02:15 <maswan> Mithrandir still awake and wants to add it to his proposal/file/whatever?
 494 02:15 <Mithrandir> I'm trying to blog so I can go to bed.  If somebody drops me a mail, I'll give it a shot
 495 02:16 <maswan> Mithrandir: Ok.
 496 02:19 <taggart> doogie: you should write up the steps you just outlined
 497 02:19 <taggart> and someone should write up the -common thing
 498 02:19 <taggart> doogie: will your doc include that? or should Mithrandir maybe add that to his?
 499 02:20 <Mithrandir> taggart: is the common thing different from what's in my proposal already?
 500 02:21 <taggart> Mithrandir: yes
 501 02:22 <Mithrandir> taggart: ok, my brain has shut down now, so I can't read it, will try to read scrollback or mail or something
 502 02:22 <taggart> Mithrandir: it says to move the files in the /lib package that don't go in $prefix/lib/$arch-os to a -common package
 503 02:22 <taggart> that's going to be a harder sell than your current proposal, but has some advantages
 504 02:23 <taggart> I guess I'll write it up
 505 02:23 * taggart/#debian-devel managed to talk himself into more work :(
 506 02:23 <Mithrandir> taggart: it's implicit in my proposal.  if you're talking about arch-indep files, that is?
 507 02:24 <taggart> Mithrandir: oh yeah it is in there
 508 02:24 <taggart> I missed it, that cool
 509 02:24 <taggart> I need to read this and not just skim it :)
 510 02:26 <taggart> Mithrandir: so even though solving this problem seems kinda crazy now, I think this is going to be the way that users will be able to migrate architectures in the future
 511 02:27 <taggart> Mithrandir: so the initial versions of every new arch will provide a way to run the old arch stuff(either via hardware or software emulation)
 512 02:27 <Mithrandir> taggart: yeah
 513 02:27 <taggart> this is long-term-big-picture stuff
 514 02:27 <taggart> Mithrandir: let's give a talk about it at debconf4, ok? :)
 515 -:- SignOff Skif: #debian-devel ("Client exiting")
 516 02:28 <Mithrandir> taggart: sure.  Who's paying my ticket? :)
 517 02:28 <Mithrandir> I'd love to go to dc4, but I can't pay the fare myself
 518 02:28 * taggart/#debian-devel passes the hat
 519 02:29 * luca/#debian-devel takes out the big bills
 520 02:29 <luca> taggart: thanks!
 521 04:19 <doogie> taggart: I'll type something up.
 522 04:20 * doogie/#debian-devel pokes taggart
 523 05:32 <aj> do we expect people to build i386 binaries on a native amd64 system, or at least in an i386 chroot on an amd64 system? (just binaries, not necessarily packages they'll send to debian or anything)
 524 05:32 <doogie> aj: taggart, mithrandir, and I came to some kind of agreement today on implementation.
 525 05:32 <doogie> I can't cut and paste, tho, on console.
 526 05:33 <calc> aj: to be able to? yea, for them to actually build it for packaging purposes i wouldn't
 527 05:33 <doogie> aj: cross-compiles
 528 05:33 <aj> calc: why not just make it easy to do a chroot?
 529 05:34 <calc> aj: imho x86 has no real reason to exist on x86-64, but other archs need multiarch for other purposes
 530 05:34 <bob2> calc: is it "safe" to bulid i386 packages in a i386 chroot on a native-amd64 system?
 531 05:34 <calc> solving it generically is considered a good idea from all the people i have heard from
 532 05:34 <aj> calc: yes, i know. why?
 533 05:35 <aj> (err. for development in particular. for running random programs, sure)
 534 05:35 <calc> aj: read taggart's page?
 535 05:36 <aj> calc: unless he has a new one, it deals with running programs, not developing them
 536 05:36 <doogie> $prefix/$arch/{lib,include}.  libfoo:i386 and libfoo:x86-64 have no files in common.  they don't even have libfoo-common.  libfoo-common exists in binary-all, and contains /usr/share/doc/libfoo{,-common}
 537 05:36 <doogie> er, third sentence is wrong
 538 05:36 <calc> aj: works for both cases afaict
 539 05:36 <doogie> s/have libfoo-common/have a doc dir/
 540 05:37 <doogie> linker uses 'magic' to load right libs from /usr/$arch/lib
 541 05:37 <doogie> gcc exists in /usr/$arch/lib, and reads /usr/$arch/include
 542 05:37 <doogie> etc
 543 05:37 <aj> calc: eh? he doesn't go into the motivation at all -- that's okay, because it's obvious why you want to run i386 bins on amd64 natively and easily (to me anyway); but it's not obvious why you can just do a chroot for development stuff
 544 05:39 <aj> (you need a chroot for ./configure to work afaics, which limits the value of having "gcc" work without a chroot)
 545 05:39 <drow> aj: Eh, why would you?
 546 05:39 <drow> I have a proof-by-example on my desk that that's not correct.
 547 05:40 <doogie> aj: we talked about patching libc to use alternative bin dirs.
 548 05:40 <aj> because you don't have native i386 binaries for various things configure might want to run?
 549 05:40 <taggart> aj: yeah I'm going to add a motivation and implications section I think
 550 05:40 <drow> Not that I'm supporting this proposal.  I share elmo's reaction: crack-tastic.
 551 05:40 <drow> unless we've switched proposals under discussion again
 552 05:40 <doogie> but your right, I haven't talked or thought about development
 553 05:40 <aj> i'm looking at mithrandir's proposal,
 554 05:41 <doogie> aj: I hate that one.
 555 05:41 <drow> aj: It doesn't work at that granularity.  I can run configure using a 64-bit bash and gcc -m32 and build a 32-bit binary.
 556 05:41 <taggart> aj: you're right is doesn't cover development, but I don't see why you couldn't develop on a system implementing it, given multiarch binutills and gcc
 557 05:41 <drow> literally just ./configure CFLAGS=-m32 CXXFLAGS=-m32 for a modern well-behaved program.
 558 05:41 <doogie> taggart: one would need all libs/includes for the other arch
 559 05:41 <aj> hrm
 560 05:42 <drow> As long as both binary types can run on the build system, you're golden.
 561 05:42 <taggart> doogie: yeah so lib*-dev would need to be multiarch too
 562 05:42 <aj> do we generally provide multiarch binutils or (an appropriate) gcc, though?
 563 05:42 <doogie> taggart: which seems easy to do, given our discussion
 564 05:42 <drow> No, certainly not.  We could; that's the "easy" part of all this.
 565 05:42 <doogie> taggart: I don't have my steps in my scrollback, nor can I cut and paste.  can you type them up?
 566 05:43 <taggart> doogie: hmm, I think they may have scrolled away for me too
 567 05:43 <drow> Like I said, I built such a system.  It's for MIPS64, and MontaVista Linux (not really Debian based).  The packaging changes were an absolute pain in the ass, but it works pretty slick.
 568 05:43 <taggart> doogie: yep
 569 05:43 <taggart> anybody logging?
 570 05:43 <aj> so, if you're on mips64 and compiling for mips, what happens?
 571 05:44 <aj> hrm
 572 05:44 <drow> aj: (Well, I'm actually cross-compiling, but native would work too) you just set CC='gcc -mabi=32' CXX='g++ -mabi=32' ./configure
 573 05:44 <braindmg> taggart: how much time in the past do you want?
 574 05:44 <drow> It uses the correct /usr/libFOO, and /usr/include works for all of the above.  For our selection of lib packages that wasn't too hard.
 575 05:45 <aj> i guess the difference between "cross-compiling" on mips64 for mips, and doing the same on mips64 for, say, alpha, is that you can run the compiled binaries and test stuff
 576 05:45 <drow> For Debian, of course, it would be an absolute nightmare.
 577 05:45 <taggart> braindmg: 2 hours please
 578 05:45 <doogie> brainf: 3.5 hours ago
 579 05:45 <doogie> taggart: nah, my time is right.
 580 05:45 <taggart> braindmg: what doogie said
 581 05:45 <taggart> and I must have been at dinner a while then

a few minutes later,

   1 <aj> hrm, what happens for python modules?
   2 <aj> taggart: still here?
   3 <taggart> aj: yeah
   4 <aj> taggart: so, python modules need to be the same arch as the python interpretor, and the library they provide hooks for (and the arch they were built for)
   5 <aj> taggart: so if we want to let get at a binary-only i386 library from python on ia64, what do we do?
   6 <aj> taggart: do we have any other choice than to just install i386 python on them?
   7 <taggart> aj: I don't think so, not without some sort of native python cross support
   8 <taggart> so that's a hole in the proposal
   9 <aj> we don't want to worry about having multiple pythons installed concurrently though, do we?
  10 <taggart> "to develop for a target you may need to install binary build tools for that target on the system, which may conflict with binary packages of another target you have installed and need on the system"
  11 <taggart> aj: well I think trying to solve the multi binary problem may open up a bigger can of worms