Re: -= PROPOSAL =- Release sarge with amd64
Raul Miller <moth@debian.org> writes:
>> > 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.
Which would be a completly new glibc package adding extra bloat to the
already streesed mirrors.
>
>> > 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.
No. That is probably not the way multiarch is going. The aim is to
have a i386 glibc and amd64 glibc and have both installable
concurrently. To get biarch support you install the multiarch dpkg and
then then respective other archs libc (+other essential/required
things).
That way there is one i386 deb, one amd64 deb and people can do
uniarch or multiarch as they wish.
>> > 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.
They have to if you want sources to still be buildable (with configure
defaulting to lib64 and all). And I think releasing debs with sources
that don't compile on the arch itself (but have to be crosscompiled)
is out of the question.
You get some unpredictable errors from configure scripts or dpkg-dev
utils errors that you only notice because the next package fails to
get the right Depends and such. It has more problems than are obvious.
>> > 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.
Did I mention that gcc/binutils will complain about any library not
matching the ABI unless lib and lib64 are seperated completly,
i.e. all lib packages are ported.
I think that alone makes a partial port unsuitable for release.
>> > [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.
We have ia32-libs but that is just a bonus that works very well and
not an intended feature. 32bit support is there, pretty much as
complete as other dists have it, but it's not considered (by the pure64
port) an essential feature for the port. Its just a bonus. We know its
not ia32 LSB compliant but so far it is ia32 LSB compatible (which is
what you would care about as debian user).
MfG
Goswin
Reply to: