Re: -= PROPOSAL =- Release sarge with amd64
Raul Miller <firstname.lastname@example.org> writes:
>> > You could install a biarch glibc which supports both 32 and 64 bit
>> > dpkg.
> On Fri, Jul 16, 2004 at 03:20:43PM +0200, Goswin von Brederlow wrote:
>> Which would be a completly new glibc package adding extra bloat to the
>> already streesed mirrors.
> We're talking about something several orders of magnitude smaller than
> what it will take to add the amd64 port to the ftp master.
You still need and want the amd64 port. I thought you were talking
about adding rudimentary biarch packages to the amd64 port?
>> > 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.
>> > 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.
> I'm not sure what you're saying here. Are you saying that gcc won't
> let you build a shared library to install in /lib if glibc is in /lib64?
No. But the 64bit linker will give you stupid warnings about unknown
abis in all the 32bit libs and the 32bit linked will give you warnings
about the 64bit libs. Or it will link 32bit and 64bit code together
and totaly screw up.
And configure scripts will think libs are there even if they are only
there for the wrong arch and such stuff.
>> > 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).
> That might be enough.
Haven't heard complains to the contrary yet.