Re: -= PROPOSAL =- Release sarge with amd64
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
Reply to: