RE: amd64 and dpkg and so
Yes, it's imperfect, and it's clunky. Dependencies between the two supported architectures won't even exist; it will be like trying to maintain two machines. 64-bit ones will overwrite the 32-bit ones and visa-versa. At least it's a starting point that gets more developers porting packages, and since there are no dependencies across the architecture, it won't require waiting for biarch support to appear in dpkg 2.0.
I've been getting calls from various groups interested in having AMD pay them to port Debian to AMD64. I've told each of them that there's nothing for us to pay for until this political issue is resolved, and that maybe by the time the politics are out of the way, I'll have money in my budget to hire some additional manpower. As much as I'd prefer taking the route we decided on months ago, we're stalled on this one political issue. The dpkg maintainer(s) won't change dpkg to allow biarch support, and we can't do much until that biarch support is accepted and standardized.
The only way I can see to break the stalemate is to find a way to support 32-bit and 64-bit binaries without changing the tools or specs. Without that biarch support, the only solutions I can think of are inelegant: Either create two autonomous sets of packages running in parallel on the same machine, or create "amd64-64b" and "amd64-32b" packages that understand how dependencies can be shared. The latter is worse, imho, because it means twice the work, and 3rd party x86 .deb packages won't understand the environment at all.
From: Arnd Bergmann [mailto:email@example.com]
Sent: Friday, August 29, 2003 4:18 PM
Subject: Re: amd64 and dpkg and so
On Saturday 30 August 2003 01:04, Martin Jungowski wrote:
> I see.... that sounds doable but I don't think that's the most
> productive solution... but it's definitely something to consider.
Sorry, but no! This is completely broken. There is no way to get
dependencies right, it will break FHS/LSB, you cannot
have the same files in two packages, and it actually requires
more work and more changes to dpkg/apt/... than the approach that
we have agreed on months ago.
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com