* Raul Miller (moth@debian.org) wrote:
> Which means it's probably not going to change. This is an easy choice
> up through system install time, but a tough one upgrade time.
It's not all that hard to handle such an upgrade path.
> > No, the only thing referencing lib or lib64 is the ld.so.
>
> I thought you were building packages which referenced /lib,
> because the effort of changing them was too high? In other
> words, that dpkg -L would list files in that location.
Yes, dpkg -L lists the files as being in /lib, but the binaries all
*reference* /lib64 for their linker, and use the standard ld.so search
path which technically means the rest of the libraries could be
*anywhere*.
> > The changes to make the uniarch -> multiarch transition go smoothly
> > and in one release, while applying to amd64 too, are completly
> > seperate to the issue and have to make the transition smoothly for
> > i386, ppc, s390, mips, mipsel and sparc. Amd64 is just on of the
> > affected archs and does in no way change the timeframe.
>
> Except, amd64 should be a biarch -> multiarch transition, not a
> uniarch -> multiarch transition.
That's simply just not an option. That's all there is to it. You can
keep saying it 'should' be this or it 'should' be that but the reality
isn't going to change- uniarch is here, and it's ready. biarch *isn't*
ready, and wouldn't be for long past sarge's release even if people all
of sudden decided it would good and wanted to work on it (not likely).
> > The change for /lib (as proposed by multiarch) is also going to happen
> > for all architectures regardless if the architecture supports
> > multiarch or if multiarch support is wanted. All architectures will
> > move the libs from lib/ to lib/<arch>-<kernel>/.
>
> As an aside, I thought the dest was <arch>-<kernel>/lib/?
No. It's ${prefix}/lib/`gcc -dumpmachine`/
> > Then why don't you? The biarch proposal have been around longer than
> > pure64 and multiarch (its successor so to speak) is still there.
>
> It might be that the only reason I have not is that I've mis-understood
> the current state of affairs. I'm still trying to understand your
> plans.
What's to understand? uniarch/pure64 in sarge now so that we have
*something*, multiarch later for all architectures, released with
sarge+1.
> > > [*] amd64 binaries can't be built from the sources in main, and
> >
> > Because there is no amd64 in main.
>
> There are no amd64 binaries in main. I'm talking about sources.
amd64 binaries can be built from the sources in main, sure, but they're
all going to install into /lib and changing *that* takes alot of effort
if you're going to do it for all of them, which is what we're interested
in doing.
> I'm glad you told me about how ld.so supports the transition.
> I'd forgotten about ld.so's role at execution time and hadn't realized
> how it would help.
>
> I'm still concerned about the physical aspects of managing the files.
It's not likely to be that much of a problem. It's certainly not going
to be any easier from biarch to multiarch than from uniarch to
multiarch, and uniarch to multiarch is what we're going to be doing for
all of the other architectures *anyway*.
> Ok, let's consider the howto for a moment.
>
> Let's say I'm installing something like openoffice, but I want the
> 32 bit /etc/mime.types to use my 64 bit gimp when displaying images.
> How do I configure this?
These situations are the ones I've already mentioned previously as not
really being supported, and to me they seem like reasonably infrequent
cases. Now, it is slightly interesting to consider that might might be
able to set things up in such a way as for this to work, but it'd be a
hack, at best, imv...
> Contrast "eventually, I won't need this app anymore because I'll be
> using a 64 bit version" and "there's a 64 bit version of this app, but
> it costs tens of thousands of dollars, so I'm using the 32 bit version --
> despite its lameness -- for now."
Do you have an example of this case? I havn't heard of one yet, not
even with Oracle.
> Both statements can be true.
Can be, but I'd like to see an example of such.
Stephen
Attachment:
signature.asc
Description: Digital signature