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@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@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@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@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@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@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@mursu packages]# And this is what's in the repository metadata:[root@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@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
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
