Kevin Kofler <kevin.kofler(a)chello.at> 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