Kevin Kofler <kevin.kofler@xxxxxxxxx> writes: > Tom Lane wrote: >> but it hasn't done anything for the problem that packages that actually >> need RPC functionality will now FTBFS for lack of a BuildRequires on >> libtirpc, if not need actual source patches (maybe they were assuming >> netdb.h would pull in rpc/netdb.h, for instance). And if they aren't >> recompiled, they'll most likely fail to run for lack of the right .so >> dependencies. > Actually, if they aren't recompiled, they'll still work, using the RPC code > from glibc. It is still there for binary compatibility, it just cannot be > used in new builds. > The problem comes up when they DO need to get recompiled, for whatever > reason. Right, I realized that when I looked a bit closer at what the glibc guys had actually done. It's summarized upthread: http://lists.fedoraproject.org/pipermail/devel/2011-May/151182.html The code in glibc is actually still there, so existing builds should continue to work the same as before. The problem is that maintainers of RPC-using programs now cannot rebuild their packages in F15 without rebasing them on a different RPC library. That seems like something that should not be happening post-release, especially not without the consent of the maintainers involved. BTW, so far as I can tell from http://pkgs.fedoraproject.org/gitweb/?p=glibc.git this change has *not* been pushed into Rawhide. So a package maintainer who wants to do the responsible thing and test out his use of the new library in Rawhide cannot do so. (I guess he can BuildRequires: libtirpc, but who knows whether things will be quite the same when glibc is still supplying the headers ...) regards, tom lane -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
