Re: -= PROPOSAL =- Release sarge with amd64
Raul Miller <moth@debian.org> writes:
> 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.
We kept the biarch repository around so packages for multiarch can be
bootstraped (if a 32/64 bit env is needed). As long as alioth doesn't
crash the pieces should remain.
>> >> > [*] 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.]
Nothing that would need dpkg-dev I think.
The DAK needs to be patched to also list amd64 in several conffiles
and lintian was patched on the last upload.
>> > 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?
The process gets the root inode entry updated (or reverted back) and
nothing else changes. I don't think there even is any performance
difference.
>> 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.
In case of OO it might be better to use a chroot. Think about updating
OO (and all the libs) a week later.
>> > 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.
That would go via
i386 -> multiarch -> arch-upgrade installed packages -> purge i386
debs and essentials
The last part someone would have to write. Its not clear yet how
adding/removing an subarch to multiarch should happen. Somehow all the
required/essential packages have to be installed for all ABIs that
have one package instaled. Purging seems even more difficult.
>> > 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
At least no great demand. The multiarch proposal is far more usefull
for the !amd64 archs even though even combined that are way less
systems. The number of users wanting multiarch on !amd64 will probably
exceed the number for amd64 by the time sarge+1 gets released. But
thats just a wild guess.
MfG
Goswin
Reply to: