Re: -= PROPOSAL =- Release sarge with amd64
> > Is it just me or are these two paragraphs contradictory?
On Sat, Jul 17, 2004 at 04:28:32AM +0200, Goswin von Brederlow wrote:
> Yes, its just you. Multiarch will not be an issue for sid for a long
> time to come. If you want it work on it but it just confuses in the
> GR.
Why?
Is this completely based on "gcc can't handle linking 64 bit shared
libraries when there's a 32 bit libc in the target directory"?
Or are there other reasons why multiarch must be more complete
before you're willing to tackle biarch?
> > Every upgrade up till now has managed to deal with replacing files in
> > the same directory as what the new package supplies.
> >
> > What is it about multiarch that makes it such a pancea for the future,
> > and such a horrible thing to start moving towards?
>
> Replacing one file with two files with the same name and path from two
> different packages with the same name but different arch for example.
Why is this a requirement?
Is this purely because of linking problems with shared libraries, or is
there some other kind of need to support two diferent instances of the
same application?
I'm trying to see the difference between "nice to have" and "critically
important" issues, and your above sentence doesn't do it for me.
> >> If you're going to do this, then why not do the full multiarch dance?
> >
> > Because you can't do everything at once.
> >
> > Also, maybe it's good to keep some distinctions in mind here. There's the
> > system on which the packages are installed (where lib and lib64 are
> > symlinks to multiarch lib dirs), and there's the packages themselves
> > (which install into /lib, /lib64, etc.).
>
> You can port all packages from pure64 or i386 to multiarch while still
> only using uniarch. You can move the libs around to the new place one
> by one by having both places in ld.so's search path.
>
> What can't be done without problems is mixing 32bit and 64bit
> libraries in the same dir. What also can't be done is use just lib64/
> because of the extra work it entails porting all the library packages.
>
> To get anything useable within a short timeframe the pure64 hack of
> linking lib64 and lib into the same place and only having one ABI
> there is the only possibility.
Can you tell me why you think "mixing 32bit and 64bit" isn't a solvable
problem?
> That said, you could start porting the base libs to be installed where
> multiarch will put them now (or to where you say) starting with either
> 32bit or 64bit as base without including the actual multiarch dpkg/apt
> support. But hey, you would still be implementing parts of multiarch.
I don't mind implementing parts of multiarch, as long as I don't have
to wait on something that I can't make available right away.
For example, I can do without "multiple instances of the same package
under the same name for different architectures" -- for the few important
packages I have to have side by side, giving them new names and manually
sticking them somewhere else is not that big a problem. You've already
been doing this for IA32.
> >> Have you made a biarch package yet? If not, please do that and come
> >> back when you have. It's painful, to do it the right way.
> >
> > What do you mean by "the right way"? And, why is that way right?
>
> In a way that has a minimum impact on the tools and sources. The les
> that needs to be changed and the simpler the change the better.
>
> Like asking dpkg where libs should end up and using that as a variable
> instead of just replacing lib/ with foobar/ (as an example).
Why does this need to be in dpkg? For contrast, what's wrong with some
table represented in some file in /etc/?
> I think only one thing has to still happen now: You have to understand
> that full biarch LSB compliance for amd64 requires most of the work of
> porting something to biarch already, that going to LSB compliance
> without going straight to multiarch is wasted work and that a clean
> LSB compliance can only be achived once everything has been ported.
>
> [as long as you want a 64bit system with the ability to also run 32bit
> and not the other way around]
Personally, I could do with either -- as a general rule, I prefer to get
things right before focussing on speed, so I'd probably actually prefer
a 32 bit system with the ability to run 64 bit.
I personally can probably live with LSB compatability for 32 bit,
instead of LSB compliance. Maybe.
--
Raul
Reply to: