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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]