Re: Result of first real test with split of runtime glibc 32 bits in a separate package

>
> On Jan 22, 2012, at 4:24 AM, [email protected] wrote:
>
>>
>>  With a glibc package without elf 32 binaries, and gcc libraries
>> also split, what holds removal of the 32 bit libc6 package in a
>> minimal chroot is:
>>
>> # LC_ALL=C rpm -e libc6
>
> (aside)
> Well that's one way to identify dependencies. One
> of these days you are going to be surprised when
> 	rpm -e libc6
> actually succeeds however: add --test (which doesn't test anything whatsoever)

  Thanks for the hint. At least I did not use --nodeps, like some
used some days ago, and "double" typed
 "sudo rpm sudo rpm -e --nodeps somepackage"
what removed sudo and rpm :-)

> or use
> 	rpm -Va --nofiles
>
> There are some subtle differences. There are 3 "contexts" attached
> to dependencies:
> 	installing	needed while installing
> 	unmarked	needed to use
> 	removing	needed while removing
> and "rpm -e" will show the union of the dependencies in
> 	removing+unmarked
> while "rpm -Va --nofiles" will show the union of the dependencies in
> 	installing+unmarked
>
> But you are actually interested in the members of the unmarked set
> implied by "? holds removal ?".

  Yes. I used rpm -e to check dependencies.

>> error: Failed dependencies:
>>        libc.so.6 is needed by (installed) lib64ffi4-4.6.2-4.x86_64
>>        libc.so.6 is needed by (installed) zlib1-1.2.5-10.x86_64
>>        libc.so.6 is needed by (installed) grub-0.97-35.x86_64
>>        libc.so.6(GLIBC_2.0) is needed by (installed) lib64ffi4-4.6.2-4.x86_64
>>        libc.so.6(GLIBC_2.0) is needed by (installed) zlib1-1.2.5-10.x86_64
>>        libc.so.6(GLIBC_2.0) is needed by (installed) grub-0.97-35.x86_64
>>        libc.so.6(GLIBC_2.1) is needed by (installed) lib64ffi4-4.6.2-4.x86_64
>>        libc.so.6(GLIBC_2.1) is needed by (installed) zlib1-1.2.5-10.x86_64
>>        libc.so.6(GLIBC_2.1) is needed by (installed) grub-0.97-35.x86_64
>>        libc.so.6(GLIBC_2.1.3) is needed by (installed)
>> lib64ffi4-4.6.2-4.x86_64
>>        libc.so.6(GLIBC_2.1.3) is needed by (installed) zlib1-1.2.5-10.x86_64
>>        libc.so.6(GLIBC_2.2) is needed by (installed) grub-0.97-35.x86_64
>>        libc.so.6(GLIBC_2.3) is needed by (installed) grub-0.97-35.x86_64
>>        libc.so.6(GLIBC_2.3.4) is needed by (installed) zlib1-1.2.5-10.x86_64
>>        libc.so.6(GLIBC_2.4) is needed by (installed) zlib1-1.2.5-10.x86_64
>>
>
> (aside)
>
> All of the versioned symbol dependencies can likely be ripped out everywhere
> and replaced (for "legacy compatibility" during the transition) with some

  I do not have any plan for any kind of transition at first, just split
32 bit libraries and have rpm know what that library provides, so that
users that do not install 32 bit packages do not need to have 32 bit
runtime. Well, this is the first step, and the only thing that can be
done without needing changes elsewhere, e.g. to stop using mklibname
and start having libfoo.i686 and libfoo.x86_64, using rpm arch info,
and what is already in the package name... But for now, need to be
lib64foo.x86_64 and libfoo.x86_64 because it is how the tools work.

> Provides: added externally like in /etc/rpm/sysinfo/Providename. I can
> go into any depth of detail, but the version of glib implies that all
> previous version symbols exist always (for glibc, not in general, where
> promoting symbol's version as if it were a so name attribute has a different
> and subtle flaw).
>
> Yes no one is prepared to rip out versioned soname dependencies everywhere
> people phear change more than they love "dependency hell" ? *shrug*.

  For now I prefer to keep using what works :-)

> Specific question:
> 	Is it feasible to make internal DT_SONAME mandatory everywhere
> 	on 2012, enforced by rpmlint checks? I personally would also force
> 	DT_SONAME into "modules" so that the rule is simple (and devising
> 	a heuristic based on paths to "modules" is not: adding DT_SONAME
> 	to "modules" hurts nothing that I know of even if not used).

  A possible example is xorg driver/input modules, that uses its own
dependency approach, using a special symbol that points to a data
structure with a common header, and fails to load if versions do
not match.

>>  These should need a rebuild to link to libffi5:
>>
>> # LC_ALL=C rpm -e lib64ffi4
>> error: Failed dependencies:
>>        libffi.so.4()(64bit) is needed by (installed)
>> lib64ORBit2_0-2.14.19-4.x86_64
>>        libffi.so.4()(64bit) is needed by (installed)
>> lib64gnome-vfs2_0-2.24.4-4.x86_64
>>
>
> (aside)
> The proposed patch for x32abi parallels the "?()(64bit)"
> markup. Instead of adding Yet More Compexity with another
> "?(x32abi)" markers, all of the appended strings "?()(64bit)"
> will be ripped out of dependencies, and a simpler (than adding
> suffixes to all soname deps) will be used instead.
>
> Unlikely to happen in 2012, the above is FYI because something
> needs to be done with both x32 and ARM abi's pretty soon.
>
>> zlib1 should follow to split elf 32, but grub would not be an
>> easy task to convert to 64 bit; fortunately, if switching to
>> grub2 it would no longer be an issue. What is holding grub2
>> is updating /usr/sbin/bootloader-config and the related
>> perl modules in drakxtools-backend to handle grub2, as well
>> as some good amount of tests?
>>
>
> Specific question:
> 	Is it feasible to consider grub -> grub2 switch in 2012

  For now I will just check a bit more grub, to work on getting
/sbin/grub to link fully static. grub2 needs whoever is responsible,
if anyone now, by drakxtools to work on updating it to use grub2,
what should not be an easy task.

>>  Too bad currently "urpmq --whatrequires 'libffi.so.4()(64bit)'" does
>> not work, so, for some extra information, in my home desktop I have
>> these other:
>>
>
> There's no reason to expect urpmq and rpm to display the same
> information atm: urpmq and rpm differ in what is commonly called
> 	Requires:

  It used to work, but that depends on the state of moon I think.
what is currently working is

$ urpmq --provides lib64ffi4
libffi[== 4.6.2-4]
libffi4[== 4.6.2-4]
libffi.so.4
libffi.so.4()(64bit)
lib64ffi4[== 4.6.2-4:2012.0]

and that library exists only as dependency until packages are
rebuilt, as now there is only lib{,64}ffi5 in the distro.

>> $ LC_ALL=C sudo rpm -e lib64ffi4
>> error: Failed dependencies:
>>        libffi.so.4()(64bit) is needed by (installed) ecl-11.1.1-2.x86_64
>>        libffi.so.4()(64bit) is needed by (installed) udisks-1.0.4-6.x86_64
>>        libffi.so.4()(64bit) is needed by (installed)
>> gstreamer0.10-ffmpeg-0.10.13-1.x86_64
>>        libffi.so.4()(64bit) is needed by (installed)
>> lib64nm-util1-0.8.6.0-1.x86_64
>>        libffi.so.4()(64bit) is needed by (installed)
>> lib64gck1_0-3.2.2-1.x86_64
>>        libffi.so.4()(64bit) is needed by (installed)
>> gnome-keyring-3.2.2-1.x86_64
>>        libffi.so.4()(64bit) is needed by (installed)
>> lib64gnomecanvas2_0-2.30.3-4.x86_64
>>        libffi.so.4()(64bit) is needed by (installed)
>> lib64ORBit2_0-2.14.19-4.x86_64
>>        libffi.so.4()(64bit) is needed by (installed)
>> lib64gnome-vfs2_0-2.24.4-4.x86_64
>>        libffi.so.4()(64bit) is needed by (installed)
>> lib64notify4-0.7.4-4.x86_64
>>        libffi.so.4()(64bit) is needed by (installed)
>> lib64poppler-glib8-0.18.1-3.x86_64

Paulo