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

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

Daniel Jacobowitz <dan@debian.org> writes:

> On Mon, Jan 12, 2004 at 03:22:40PM +0100, Julian Mehnle wrote:
> > Josselin Mouette wrote:
> > > Le dim 11/01/2004 à 08:00, Goswin von Brederlow a écrit :
> > > > The currently implemented idea was to rename the amd64 package of
> > > > libfoobar to lib64foobar and have amd64 binary packages depend on that
> > > > name instead. libfoobar.so goes to /lib and lib64foobar.so to
> > > > /lib64. That works so far.
> > >
> > > Am I the only one to think the whole /lib64 idea is fundamentally
> > > broken? We already have ia64 without this. We can build a very similar
> > > system for amd64, introducing a new arch. Then, ship a few 32-bit
> > > compatibility libraries for 32-bit proprietary software.
> > 
> > Yes, I also think the /lib64 idea is fundamentally broken.
> 
> Having actually used it, for both PowerPC64 and MIPS64, I disagree that
> /lib64 is broken.  I think that Goswin either misspoke above about
> lib64foobar.so or has a very bad idea - it's suppose to be
> /lib/libfoobar.so.1 in libfoobar1, and /lib64/libfoobar.so.1 in package
> lib64foobar1 (or whatever you feel like calling it).

The initial mail only deals with

libfoobar_1.2.3-i386.deb + lib64foobar_1.2.3-amd64.deb

versus

libfoobar_1.2.3-i386.deb + libfoobar_1.2.3-amd64.deb

while both can be installed at the same time.

Both ways need /lib/libfoobar.so.1 + /lib64/libfoobar.so.1 and both
ways need the split of common files into an extra package. The only
way around the split is producing a bloadted package containing both
libs, which many would object.

> There are always good reasons to build packages on a different ABI. 
> When I did this for MIPS, we did (are doing) a base system of N32,
> complete O32 libraries for compatibility with existing applications,
> and complete N64 libraries for large applications needing the memory
> space.
> 
> However, we (after much discussion) did the compatibility libraries as
> separate packages from our existing o32 MIPS architecture.  I still
> think that is a wiser way to go than attempting to mix and match from
> different architectures.

Thats fine if you only have a handfull of packages you have to change
the Depends/Build-Depends lines for. Its hell on amd64, wich brings us
back to the problem of renaming the deb files.

MfG
        Goswin