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 18:51, Scott James Remnant wrote:
> 
> > You won't be able to handle all this inside dpkg with magic, the
> > packages will have to be manually tailored to not conflict with their
> > 32-bit counterpart (omitting shared /share is probably the easiest) --
> > at which point they become totally different packages anyway!
> > 
> In fact, because the 64-bit package will be missing many key files
> because it happens to share them with the 32-bit package, it's going to
> Depend on the 32-bit package...

That goes against the goal of having a pure amd64 system, a pure i386
system or a mixed system. Currently there are several amd64 packages
that depend on their i386 counterpart for common file, which is the
easiest to do, but I would rather see them being split properly into
i386, amd64 and common.
 
> So we have libfoobar0, which is the standard 32-bit package and
> lib64foobar0 which contains those files that differ for 64-bit and
> depends on the former.
> 
> Package: foo
> Depend: libfoobar0
> 
> (we don't care which one we get)

What if foo is a old or 3rd party package? That would require the i386
libfoobar0 package to be pulled in and no any architecture.
 
> Package: foo
> Depend: lib64foobar0
> 
> (we want 64-bit)
> 
> Problem solved, isn't it?

That requires nearly every Build-Depends and Depends line to be
modified manually, which is what we try to avoid.

> 
> Scott

Idealy you just take the existing source package, dpkg-source -x,
debuild, done. At least for binary packages that should work. And for
library packages a minimum of work should suffice.

MfG
        Goswin