How multilib is done needs changing

[email protected] Thu, 26 Jan 2012 03:42:31 -0200 (BRST)
Newsgroups gmane.linux.mandrake.cooker.devel
Message-ID <[email protected]>
  Initial spec at

https://blueprints.launchpad.net/rosa/+spec/rosa-multilib

  I have it done for x86_64 and i586 (actually, i586 is not
affected, tested just to ensure something did not break as
an unexpected side effect or bug added to specs) and running
for some weeks for gcc, and some days for glibc.

  I had not submitted packages, initially expecting to submit to
main/testing, to avoid any possible issue during perl updates.
But since it is just a rebuild with split of 32 bit libraries,
the only issue would be choosing to revert, what could be done
with minimal problems, i.e. change back from:

lib64foo1-2-3-mdv2012.0.x86_64.rpm <- 64 bit libraries
libfoo1-2-3-mdv2012.0.x86_64.rpm   <- 32 bit libraries

to have only one library package.


  Example of what I have installed:

$ rpm -q lib64stdc++6 libstdc++6
lib64stdc++6-4.6.2-11-mdv2012.0.x86_64
libstdc++6-4.6.2-11-mdv2012.0.x86_64


  Special case is glibc, that is kept named as glibc, but
there is a new 32 bit only package, with some binaries:

$ rpm -q libc6
libc6-2.14.90-12.1-mdv2012.0.x86_64

(yes, the name could also be glibc32 or a variant).

  I understand that different people have different ideas of
how this should be done, should not be done, etc, and thus,
any comment is welcome.

  Personally, I do not like it much, but other than doing
nothing, this is the least intrusive way to implement it.
I would prefer to have it implemented as:
  libstdc++6-4.6.2-11-mdv2012.0.x86_64 <- 64 bit libraries
  libstdc++6-4.6.2-11-mdv2012.0.i686   <- 32 bit libraries
have rpmbuild automatically split the packages, generate
enough dependency metadata, and have both in the same
repository. That is, pretty much what fedora does. But that
would have implications with %mklibname and a lot of other
stuff, like urpmi, repository updates, etc.
  Also, to not be intrusive, -devel packages require both,
example:

$ rpm -q --requires lib64stdc++-devel
lib64stdc++6 = 4.6.2-11
libstdc++6 = 4.6.2-11
python(abi) = 2.7
devel(libgcc_s)
devel(libgcc_s(64bit))
devel(libm)
devel(libm(64bit))
rpmlib(PayloadIsXz) <= 5.2-1

$ rpm -q --requires lib64stdc++-static-devel
lib64stdc++-devel = 4.6.2-11
rpmlib(PayloadIsXz) <= 5.2-1

---%<---
  For a more complete example, this is what I have:

$ urpmq --media gcc --requires lib64stdc++6 2>/dev/null
ld-linux-x86-64.so.2()(64bit)
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.2)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libgcc_s.so.1(GCC_3.3)(64bit)
libgcc_s.so.1(GCC_4.2.0)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)

  And this is what currently is in the distro:

$ urpmq --media main --requires lib64stdc++6 2>/dev/null
ld-linux-x86-64.so.2()(64bit)
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)
ld-linux.so.2
ld-linux.so.2(GLIBC_2.3)
libc.so.6
libc.so.6()(64bit)
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.2)
libc.so.6(GLIBC_2.3.2)(64bit)
libgcc_s.so.1
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)
libgcc_s.so.1(GCC_3.0)(64bit)
libgcc_s.so.1(GCC_3.3)
libgcc_s.so.1(GCC_3.3)(64bit)
libgcc_s.so.1(GCC_4.2.0)
libgcc_s.so.1(GCC_4.2.0)(64bit)
libgcc_s.so.1(GLIBC_2.0)
libm.so.6
libm.so.6()(64bit)
libm.so.6(GLIBC_2.0)
libm.so.6(GLIBC_2.2.5)(64bit)
---%<---

  I will hold a bit more submit of gcc and glibc with the
32 bit library split in case someone has any issues. I also
plan to submit a newer grub, with /sbin/grub linked statically,
so that the only things, on a non devel system that would case
the need to install 32 bit libraries would be some packages
needing to rebuild with lib{,64}ffi5 and zlib.

Thanks,
Paulo