Raul Miller <[EMAIL PROTECTED]> writes:
>> > 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?
Read the biarch and multiarch proposals and past discussions.
(FYI: Multiarch is the one with less work being needed.)
>> > 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?
You have biarch capabilities or archive bloat (which is an issue for
being included in sid).
> 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?
Its a problem with avoiding archive bloat through biarch capabilities
in dpkg. You end up with multiple /usr/share/doc/package/copyright files.
Again, see past discussions.
> 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?
Because you won't get upstream to accpet patches and the same probably
goes for the Debian maintainers for binutils and gcc.
You will always get the warnings there which I feel is unacceptable
since its avoidable.
>> 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.
That is what ia32-libs is doing. But its only ment to support thrid
party binaries and not for ia32 debian packages.
>> >> 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/?
'dpkg-buildpackage -aamd64' and 'dpkg-buildpackage -ai386'. Remember,
you are aiming for multiarch support so the right arch/path is nothing
fixed.
>> 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.
Do you need to build libraries under debian to be used on a non debian
amd64 LSB compatible system?
Because that is the only thing breaking (the deb file contains the lib
in the wrong dir) we know of.
> --
> Raul
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
