Re: 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.

  I believe probably the most sane way to do it in Mandriva
is to have 32 and 64 bit libraries split in 2 packages, but
keep -devel packages with both, 32 and 64 bit static libraries,
or .so symlinks. This on the sense of at first not wanting
to break or need changes to any existing package or spec file,
or at least if happening, only on very special cases.

>> 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

  Triarch x86_64! Should be a good test environment for a distro
bootstrap, just chroot to it in your cooker computer :-)

>> 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.

  This could require some redesign on different tools or
repositories, for example, to have libfoo.x86_64.rpm and
libfoo.i686.rpm in the same repository, instead of having
lib64foo and libfoo identifiers.

>>> 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.

  For now I am experimenting with what I have full control,
that is to split 32 and 64 bit libraries, but keep -devel
packages with both arches, to avoid dependency hell, and
most likely breaking any package that has a build requires
like libfoo-devel and actually requires 32 bit libraries,
e.g. valgrind.

>>>  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.

  This was more to try to have some insight on possible other
issues, or things that might break and require more than a
rebuild to become functional again. E.g. java-1.5.0-gcj
should only require a rebuild, while gccxml depends on
it being updated for gcc 4.7. Anyway, most packages that
should have build issues are c++ code.

>> hth
>>
>> 73 de Jeff

Paulo