Re: gcc 4.7

Begin forwarded message:
> 
>> Hi,
> 
>> My plan for gcc 4.7 in Mandriva is in 2+ months to have
>> it default. In the meantime, it could be the moment for
>> some changes that were suggested, and these include:
> 
> Yes it is the moment where change might be possible.
> 
>> 1. No longer provide or build multilib, and instead enable
>>   32 and 64 bit repositories.
> 
> What Mandriva is currently doing is often mixing elf32/elf64
> in the same package. That usage is different than any other distro.
> 
> The question as phrased is essentially asking is whether what SuSE
> is doing, splitting elf32 and elf64 into separate distros (and SuSE
> also has a 3rd distro product that has both elf32/elf64 packages)
> should be used.
> 
> The 3rd alternative (what RedHat is doing) has a pkg granularity where
> each pkg is either elf32 or elf64, but both elf32/elf64 are mixed in the
> same repositories.
> 
> Ultimately elf32 != elf64 and how one differentiates matters little. but
> there are huge differences in how build systems are constructed and
> how product is marketed and/or supported dependent on the "multilib" choice.
> 
> Note also that x32abi is "supported" in 3.2 kernels and presumably there
> will be usage cases defined soon. There already is a (rather feeble imho) patch
> to rpm to handle x32abi being tracked here:
>    https://blueprints.launchpad.net/rpm/+spec/rpm-x32abi
> 
> There are some complex issues tied to ARM abi's similar to x32abi; but cooker@ isn't the place
> for arm discussions.
> 
>> or
> 
>> 2. Split 32 and 64 bit libraries in different packages.
> 
> This is the RedHat model. There's deeper benefits here because
> this is/was what RPM "multilib" was designed for:
> 	Every package has only one of elf32 or elf64 (or x32abi) within.
> and so various functionalities in RPM that are currently disabled for
> Mandriva can just be turned on. Otherwise Newer! Better! Bestest!
> packaging functionality will have to be devised and discussed.
> 
>> or
> 
>> 3. Other? do nothing?
> 
> Doing nothing increasingly has a hidden cost, but does not need
> any discussion or decision.
> 
> I'd vote for 2) for many reasons; there is a risk to per-package
> elf32/elf64 split that isn't in 1)
> 	You need to be very careful choosing the minimal manifest.
> The original choice @redhat (in RHEL4 iirc) is was
> 	All libraries (but not executables) will be distributed.
> The problem that was overlooked there (marketing made the decision when
> engineering deadlocked @redhat) is that packages have both libraries
> and executables within (in @redhat packaging: mandriva does a better job
> splitting libs <-> executables)
> 
> There is also the possibility of being able to do both 1) and 2)
> if mirrors can be changed to accommodate per-abi (essentially per-arch)
> splits instead of what is currently in use.
> 
> With elf32 <-> elf64 split by package and by repository, then distro
> product can be composed in several ways on need (like SuSE) and
> with each package dependent only on its own arch (or no arch) then
> the QA becomes in principle a bit easier.
> 
>>  MDawkins has been doing some work with initrd, static
>> binaries and uclibc, what may be affected. What else,
>> eglibc, klibc, dietlibc, bionic libc?
> 
> Are all these glibc's actually needed? Perhaps the better split
> (than elf32 <-> elf64) would be along the usage cases for
> each of those glibc's instead.
> 
> hth
> 
> 73 de Jeff
>