* Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) wrote: > Stephen Frost <sfrost@snowman.net> writes: > > > 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 > > It is not. At least not for libs. You need to change every /lib/ to > /lib64/ for example, without breaking /lib/ on other archs. Clearly that's only true if we end up using /lib64. If we use /lib then it looks the same as the other 64bit archs. > > 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. > > Already have one for the debian-amd64 repository thats available on alioth. I'm talking about an official one that's linked into wanna-build and actually puts things into unstable. Unfortunately we don't have one of those yet, though hopefully we will once the the multiarch/native/etc issues get hammered out. > > > > 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. > > Repeating myself again in the hope you might read it this time: > > The main reason for /lib and /lib64 on amd64 by now is because > everyone else is doing it. Everyone else hacked up something quick for amd64. Everyone else doesn't support other archs. Everyone else can go sit on a fence. > Have fun with your packages when upstream starts patching in /lib64/ > and you have to patch it out again for debian. Yeah, that would be > fun. Going to have to do it one way or the other unless you think they're going to get it right for both amd64 and alpha. Either that or we need to start making our 64bit archs use /lib64 and have an empty /lib, that'd be great, really. Stephen
Attachment:
signature.asc
Description: Digital signature