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

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

Scott James Remnant <scott@netsplit.com> writes:

> On Sun, 2004-01-11 at 21:23, Goswin von Brederlow wrote:
> 
> > Just think of all the scripts that use /bin/bash, /bin/sh, .... All
> > those would break with /bin64/bash, /bin64/sh, .... I don't think
> > anyone will go for a bin / bin64 split.
> > 
> Then I don't understand how you're going to deal with this:
> 
> binpkg depends on libpkg.
> 
> Part of the exported API of the library in libpkg is a structure, the
> binary-image of this structure changes depending whether you are using
> the i386 or amd64 version of this library[0].
----------------------------------------------------------------------
> [0] this isn't an uncommon problem, some of the core fundamental types
>     such as those for measuring times, file sizes and the like have
>     different sizes on 32-bit and 64-bit systems.
----------------------------------------------------------------------

That is the least of the problem. The calling convention alone is
totally incompatible. Amd64 has a lot more registers than i386 and
uses it.

> Under your proposals, we supply both a libpkg:i386 and libpkg:amd64.
> 
> What do we do about binpkg?  Only one of the following two options
> spring to mind:
> 
> 1) Provide both binpkg:i386 and binpkg:amd64, each depending on the
>    library with the correct ABI.  Except unless you use bin64, these
>    will not be dual-installable meaning that only one of the libraries
>    will ever need to be installed at the same time as well.
>
> 2) Provide only an amd64 (or i386) version of binpkg.  But this makes
>    the dual-ABI libraries redundant, we only need whichever is matched
>    to the binary.
> 
> Once you take into account the various inter-library dependencies where
> this is an issue, you'll find you pretty well almost need an all-i386
> bin or all-amd64 bin anyway.

You can install make:amd64 and gcc:i386. Both need libc6. That the
normal case where you need both abis.

For the special case of binpkg and just binpkg depending on libpkg
there is no need for dual installability of libpkg. libpkg:i386 can
happily conflict with libpkg:amd64 if the maintainer wants.

Since some users want binpkg:i386 and others want binpkg:amd64 to be
installed both libpkg achitectures will still be needed. You just save
the dual installability part. I don't see a problem there.

Why is there even a libpkg.deb? The only use of libpkg.deb is to be
installed when binpkg.deb is installed and it can be removed when
binpkg is removed. And neither can be a binary-all package. Why not put
the library into binpkg too and be done with the problem?

The /bin and /usr/bin on the amd64 system is quite well mixed with 32
and 64 bit binaries. There is a need for a mixed i386/amd64 system,
the need for a i386 only system (for i386 owners obviously) but
only a desire for an amd64 only system.

The i386 support is needed for 3rd party products. The amd64 support
is needed for the larger address space, e.g. for a big mysql/postgres
DB. People who need both need a mixed system. The question is not if
Debian provides a mixed system but how nicely it is done. I feel your
still arguing about wether there even should be a mixed system.

> > > > > 	/etc/* -> /etc64/*
> > > > > 		(config files may be architecture specific)
> > > > 
> > > libc6 springs immediately to mind, now you mention it.  Others (just on
> > > my system from a quick grep) include libnss-db, libpam-modules, libao2
> > > and libruby1.8.
> > 
> > Where is the problem with those packages? Whats architecture dependent
> > on their config files?
> > 
> Are you planning on submitting your change to the FHS that configuration
> files are now required to be architecture independent?  Because that's
> certainly exactly the opposite of what the FHS says.

First show me that there is a problem at all. The configfiles in etc
are host dependent but I would be surprised if there is even one
configfile used by a library that is architecture dependent.
Configfiles tend to be asci which greatly reduces the likelyhood of
the problem.

And rather than changing the FHS I would patch the software to use an
architecture independent format instead and convert it on the fly when
reading.

> Scott
> 
> [0] this isn't an uncommon problem, some of the core fundamental types
>     such as those for measuring times, file sizes and the like have
>     different sizes on 32-bit and 64-bit systems.

Just as a personal note: time_t should be 64 bit on all arch. The
stupid 32 bit time_t will be a problem soon enough. File sizes (off_t)
better be 64 bit everywhere. Everything else is a BUG, activate LFS.

MfG
        Goswin