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

Re: dpkg and debhelper patches for lib64 support



On Tuesday 10 June 2003 21:25, marc.miller@amd.com wrote:

> Having said that, there are times when you can substitute a 32-bit
> dependency.  Not in the case of libraries, but if you need to execute a
> script, the interpreter (e.g. bash, perl, tcsh, python) can be 32-bit or
> 64-bit.  At trade shows, we've also run 64-bit X apps within a 32-bit X
> environment to show how easily you can mix programs.  I think that's
> possible because the X protocol is platform-independent, and only tells the
> local X server what to display.  ...but within that 64-bit X application,
> each required library is 64-bit, and within the 32-bit X server, each
> required library is 32-bit (so you could have something like a libX.so.#
> existing in both lib and lib64 directories being accessed at the same
> time).
>
> Most existing AMD64 distributions solved the problem by making all
> dependencies for a 64-bit package be 64-bit.  That's the easiest way to go
> about it.
>
> Personally, I'd love to see a Linux OS which correctly identifies
> situations where 32-bit packages can be substituted for 64-bit ones.  If
> Debian did this, I think it would be the first truly hybrid 32-bit & 64-bit
> Linux distribution (all AMD64 distributions I know of are 64-bit with
> support for 32-bit packages and often both 64-bit and 32-bit development
> capabilities).  But identifying that for each package is a non-trivial
> undertaking.  I would be the last to volunteer.

Marc,

you seem to have largely misunderstood what Gerhard has proposed
and you are at least two steps behind here. Gerhards patches implement
a system to make it easy to create a mixed 32/64 bit environment that
takes care of all dependencies. It has been shown to work on s390x
and on amd64, the question is if the dpkg maintainers are willing
to accept the necessary changes or if there are better ways to do it.

	Arnd <><



Reply to: