Re: -= PROPOSAL =- Release sarge with amd64
> > If you don't provide a dual 32/64 bit amd64, your transition strategy
> > is going to be "install it on a different partition" or "backup, wipe
> > and reinstall".
On Fri, Jul 16, 2004 at 09:14:25AM +0200, Goswin von Brederlow wrote:
> That is the plan and the current implementation. As such pure64 has
> succeeded and fullfilled its expectations.
>
> There is no and never will be a transition plan from i386 to
> amd64. That is just not possible. You can't replace dpkg since then it
> lacks its libc and you can't replace libc since then dpkg lacks the
> old one. And so on for every other essential package.
You could install a biarch glibc which supports both 32 and 64 bit
dpkg.
> > And I see nothing in the multiarch spec that makes migrating from a
> > /lib64+/lib system any more difficult than migrating from a /lib system.
>
> Correct. Hence pure64 doesn't make the transition more difficult.
As long as you're willing to provide a biarch glibc in pure64, I'd
have to agree with you.
> > What I don't see is any sane reason to not start out from a /lib64+/lib
> > system. Maybe there is one, but telling me how it's clear to you what
> > I have or haven't though doesn't convey any specifics to me.
>
> /lib64 requires at least 2000 source packages to be changed. For the
> details on those numbers see the biarch proposal discussions.
But they don't all have to be changed right away.
If we ever did get into a situation where "everything has to change at
the same time", we'd have a system we couldn't upgrade.
> > Which seems to indicate to me that multiarch has no problem absorbing
> > /lib64/. And you seem to be implying that asking for /lib64/ on amd64 is
> > a bad thing to ask -- if that's not what you're saying, please try again.
>
> One doesn't change the other. Changing lib -> lib64 is a lot of
> work and not possible with sarge pending.
Any such changes are going to have to happen on a package by package
basis anyways.
> > [And, as for clean upgrade, just make the packages optional, and give
> > them a Conflicts: task-amd64-multiarch-upgrade or some such and they'll
> > be fairly easy to clear out of the way when the time comes.]
>
> Violates policy. Priorities must match with the Depends.
We're talking about mixing architectures here. We've not yet
developed formal policy for mixed architectures.
> >> http://alioth.debian.org/docman/view.php/1314/21/debian-amd64-howto.html
> >
> > I agree it's possible. But it's quirky. [And, tedious, when you
> > have a lot of such apps.]
>
> Its one entry in your etc/fstab. Doesn't get more work for more apps.
That depends on how you're using those apps.
> What the pure64 people said is that we don't even want to support
> 32/64 bit.
And the outstanding bug report to ftpmasters has "support 32/64 bit"
during the transition as the issue they've raised.
> We acknowledge the possibility and keep all possible ways open to add
> it at a later time (sarge+1 with multiarch) but for now we realy don't
> care.
Except, it's when people are moving from 32 bit intel systems that 32/64
has the most value.
That said, it doesn't have to be beautiful "we support every 32 bit
debian package". It just has needs to be of the form "we support 32
bit forms of the base system" such that anyone who needs to add 32 bit
support for some other package has a way of doing so.
Perhaps you've already got this, but you seem to be claiming otherwise.
--
Raul
Reply to: