Re: Upcoming Debian multiarch support (amd64, sparc64, s390x, mips64) [affects sarge slightly]

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Stephen Frost <sfrost@snowman.net> writes:

> * 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

It is not. At least not for libs. You need to change every /lib/ to
/lib64/ for example, without breaking /lib/ on other 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.

> > > 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

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.

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.

MfG
        Goswin