* Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) wrote: > Stephen Frost <sfrost@snowman.net> writes: > > I hardly see it as a problem when we add a new arch that we have to > > recompile all the binaries. I'd expect it in general, actually. > > The 32 bit support in amd64 is eventually just for binary only stuff. > Good luck recompiling those. I was pointing out that being concerned about recompiling all the binaries doesn't make sense- we're going to be doing it for everything in the archive anyway. > Everything else will most likely be ported to 64 bit at some stage. If > someone is willing to port something I see no reason to not include > the result in debian-amd64. Through that eventually everything of > intrest will be ported. What porting? We already compile for 64bit architectures, it should be reasonably straight-forward to do the same for amd64. It shouldn't be an issue of if someone is 'willing' to port something, we should have a buildd that builds amd64 binaries, just like we have a buildd for every other architecture. If we don't then, again, might as well forget properly supporting the architecture at all. > > Let's not lump amd64 into the exact same boat as sparc64 and company. > > On amd64, 64bit is faster and so, yes, we really *should* recompile > > everything for it. The same is not true on some of the other archs > > where 64bit is slower. > > The problems are the same, the extend of the probems (amount of > packages affected) is different. That depends on how you look at it. Packages affected by sparc64 on sparc32 -> Small, it's slower but needed for apps which use lots of ram Packages affected by amd64 on i386 -> Large, amd64 is faster and most people will want everything running in 64bit. Lots of things affected by /lib64 Packages affected by i386 on amd64 -> *Small*, it's slower, and you only need the i386 stuff for commercial/non-free. Some commercial/non-free not supported at all if things are hard-coded (no /lib64, 64bit lib, 32bit /lib32). Packages affected by i386 on ia64 -> Same as i386 on amd64, I believe, and that's how it's being treated, from what I understand. The only point at which we have a large number of packages being affected is when we have to go through and change everything to support amd64 as /lib64 and allow for i386.debs to be installed directly onto amd64 systems, which is all done to support commercial/non-free applications that wouldn't be able to handle a /lib32, which isn't all that common. Stephen
Attachment:
signature.asc
Description: Digital signature