Re: -= PROPOSAL =- Release sarge with amd64
On Fri, Jul 16, 2004 at 02:43:46PM +0200, Goswin von Brederlow wrote:
> No. There never will be a biarch amd64 unless you pick up the pices
> and make one.
My concern is that it be possible for me to pick up the pieces and
make one.
> >> > [*] amd64 binaries can't be built from the sources in main, and
> >>
> >> Because there is no amd64 in main.
> >
> > There are no amd64 binaries in main. I'm talking about sources.
>
> You still need build-essential to build anything.
True.
> You don't need dpkg sources to build something.
Except deb packages. [Ok, granted, the file format is transparent enough
that you can do this by hand. But I expect that ftpmaster uses dpkg
and lintian in some of the incoming support scripts.]
> > I'm still concerned about the physical aspects of managing the files.
>
> Think about /usr/share/doc/package/copyright. libc6_i386.deb and
> libc6_amd64.deb have to have that file but then dpkg complains.
>
> Mutliarch is fun. But its all in the proposal (or not yet solved at
> all).
For now, just laying the groundwork is [probably] enough.
> If you like a challenge tell us why sbuild works for all packages
> except for zsh/zsh-beta. For those two the build looks up in state
> "T". Using debuild in the same chroot works perfectly.
I'll see if I can figure it out.
> > Let's say I'm installing something like openoffice, but I want the
> > 32 bit /etc/mime.types to use my 64 bit gimp when displaying images.
> > How do I configure this?
>
> you mount the 64bit / inside the 32bit chroot (thus creating a circle)
> and then configure the mime.type to use dchroot to change back into
> 64bit.
Doesn't this blow efficiency out of the water? Doesn't this mean
that VFS has to maintain two independent references to the files
(and libraries) in question?
> Or you install all the libs needed for OO in /emul/ and run it without
> chroot.
That's what I'm hoping for, I think.
> > Ok. Maybe if we can put to rest the 32->64 bit transition planning
> > issues, ftp-master will speak up on this other one.
>
> The plan is as follows:
>
>
> i386 amd64 sarge/sid now
> \ /
> \ /
> _\| |/_
> multiarch
> / \
> / \
> |/_ _\|
> multiarch i386 multiarch i386/amd64 sarge+1
Yeah.
Of course, there's an expressed desire to support i386->amd64 (ideally
through apt with minimal manual intervention), and even if you're not
going to do a thing to support it, it's important that we make sure it
remains possible.
> > Contrast "eventually, I won't need this app anymore because I'll be
> > using a 64 bit version" and "there's a 64 bit version of this app, but
> > it costs tens of thousands of dollars, so I'm using the 32 bit version --
> > despite its lameness -- for now."
> >
> > Both statements can be true.
>
> As a sidenote: People that can spend tens of thousands of dollars on
> software usually have the time to setup a chroot properly. :)
Right.
Of course, I was talking about the people who didn't have those tens of
thousands of dollars to spare.
> > The value of 32 bit support is at transition time, and that's decided
> > on a program by program (or package by package) basis for each user.
>
> Absolutely. And the overall opinion goes towards that the transition
> will be complete before sarge+1 comes out for all relevant
> purposes. Hence the don't care attitude towards 32bit, it will solve
> itself before debian can solve it. :)
Are you saying that you don't expect there to be any need for i386
support in sid?
--
Raul
Reply to: