Re: multiarch/bi-arch status (ETA) question
Paul Brook <paul@codesourcery.com> writes:
> On Tuesday 05 July 2005 19:46, David Wood wrote:
>> On Tue, 5 Jul 2005, Hugo Mills wrote:
>> >> I guess I can only ask... what... on... earth... was the problem?
>> >
>> > See below...
>>
>> Actually, I don't see where you've said what was objectionable about
>> multiarch.
>>
>> > Well, let's say you want to install a 32-bit xine. That's written
>> > in C, so you have to have a 32-bit glibc. So, you use dpkg to install
>> > the 32-bit version of glibc2. But... you can't, because you already
>> > *have* a package called glibc2 installed, which is the 64-bit version.
>>
>> No, you misunderstand. I don't expect that to work. It's obvious that if
>> you just made the directory structure switch you still have a long way to
>> go before you can install two different glibc packages. I'm just saying,
>> why not make the directory structure switch and then _start_ doing the
>> work of adding support to the package system/packages. Then, as I said:
>
> Until you have a coherent and generally acceptable plan for how to handle the
> hard bits is there any point doing anything (other than as proof-of-concept)?
> If you start migrating things before the long-term strategy has been agreed
> you risk having to do another migration because you got it wrong.
>
> Paul
We already have (had) a proof of concept. We have a lot of patches
too. The only thing missing is the fine detail and cruciating testing
by tons of users.
I think the best next step is to get gcc and binutils support for
multiarch added and tested. It seems the multilib stuff is currently
broken again so it might be a good time to fix it the right way[tm].
Getting the toolchain adapted is more important than some trivial mv
commands for libs.
MfG
Goswin
Reply to: