On Sat, Jul 17, 2004 at 07:00:58AM +0200, Goswin von Brederlow wrote: > > 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.
You seem to be answering a question I'm not asking. > Again, see past discussions. Which ones, specifically? > > 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. In other words, you'd have to fork those packages until the issues got resolved? > You will always get the warnings there which I feel is unacceptable > since its avoidable. Then leave that as a known bug until multiarch is ready. Doesn't sound like a showstopper for biarch. Or, if it is too annoying to tolerate, then it's worth addressing. > > 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. That's half the issue. > >> >> 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. Let me ask that question a different way: what's the sequence of events leading up to the point where dpkg-buildpackage -a works? Or do you expect that -a has to work before any other multiarch work can be done? > > 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. Me personally? No, I don't need that. But that's not the only thing breaking. For example, upgrade from i386 is broken. Which is sad. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
