[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

* 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

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.


Attachment: signature.asc
Description: Digital signature

Reply to: