Broken (glibc) dependencies in f19 update-repository metadata

[Panu Matilainen]

On 07/06/2013 06:12 PM, Jakub Jelinek wrote:
> On Sat, Jul 06, 2013 at 01:31:48PM +0300, Panu Matilainen wrote:
>>
>> Something is broken wrt f19 updates and updates-testing repo
>> metadata, note the required glibc version between the rpm version in
>> main repo vs updates-testing:
>>
>> [root at mursu ~]# repoquery --releasever=19
>> --enablerepo=updates-testing --requires
>> rpm-build-4.11.0.1-2.fc19.x86_64|grep ^libc.so
>> libc.so.6(GLIBC_2.17)(64bit)
>> [root at mursu ~]# repoquery --releasever=19
>> --enablerepo=updates-testing --requires
>> rpm-build-4.11.1-1.fc19.x86_64|grep ^libc.so
>> libc.so.6(GLIBC_2.8)(64bit)
>> [root at mursu ~]#
>
> What does look broken on that?

Whats broken about that is that it does not match reality.

> The thing is (almost?) every newer glibc
> version adds some symbol versioned symbols, but in most releases
> they are just completely new entrypoints that at least for some time
> are used by quite a few packages.  In a few releases a very commonly used
> symbol is either added, or more commonly changed and symbol versioned.
> That is e.g. regexec@@GLIBC_2.3.4 (with older regexec at GLIBC_2.{0,2.5,etc.}
> around; this has been changed when new eflags flag has been added to it,
> so that code compiled against newer glibc can rely on the flag being
> handled) or memcpy@@GLIBC_2.14 (that has been added on x86_64 because
> there were just too many broken programs that haven't heard about the
> difference between memcpy and memmove and it was decided to add a
> compatibility hack for those buggy programs by aliasing memcpy at GLIBC_2.2.5
> to memmove and only doing more aggressive copying that assumes
> no overlap at all for newly linked programs) or I guess for
> glibc 2.17 it is probably clock_gettime@@GLIBC_2.17 and friends (that
> previously has been available only from libpthread, and now is also
> exported from libc.so.6*).
>
> As glibc maintainance in Fedora has been changed in the last few years,
> where rawhide only gets new glibc release when it is released (previously
> rawhide always had development snapshots of glibc and glibc releases
> were tied up with Fedora releases, so glibcs were (usually) released shortly
> before freezes), that pretty much means only very few packages in the
> distro get new glibc symbols upon GA and more can have them during updates.

Yes, well known. The thing here is that the actual package dependencies 
are just fine, the *repository metadata* is broken on these glibc 
dependencies. Rpm records all the different version requirements from 
symbols, but createrepo "optimizes" this by collapsing them to the 
highest requirement found. And *that* is what's broken on f19 updates 
and updates-testing repositories.

My original mail included this example already, but lets try again. This 
is what the actual package has on glibc:

[root at mursu packages]# rpm -qp --requires 
rpm-build-4.11.1-1.fc19.x86_64.rpm |grep ^libc.so
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.17)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.8)(64bit)
[root at mursu packages]#

And this is what's in the repository metadata:

[root at mursu packages]# repoquery --releasever=19 
--enablerepo=updates-testing --requires rpm-4.11.1-1.fc19.x86_64|grep 
^libc.so
libc.so.6(GLIBC_2.3.4)(64bit)
[root at mursu packages]#

"libc.so.6(GLIBC_2.3.4)(64bit)" is one of the dependencies, but that's 
nowhere near the highest version dependency there is. What should be in 
the repodata after the "collapsing" is "libc.so.6(GLIBC_2.17)(64bit)", 
which is true in the main f19 repository but not in the update-repositories.

	- Panu -


>
> 	Jakub
>