F15's /usr/include/rpc has disappeared; <netdb.h> uncompilable
tgl at redhat.com
Fri May 6 23:20:08 UTC 2011
Adam Williamson <awilliam at redhat.com> writes:
> On Fri, 2011-05-06 at 10:59 -0400, Tom Lane wrote:
>> Well, if they think this is their beta test period, it still merits
>> asking why the heck this type of change is going in now. I agree with
>> Dave that this looks like development material, not near-release bug
>> fixing. It's particularly bad that they are making what amount to API
>> changes long after all dependent packages are frozen. Who knows how
>> many F15 packages are now going to ship in a FTBFS state?
> In fact, you can see this has already happened:
> has -6 karma at present. When it hit -3, it got unpushed. Of course,
> this reminds us of a problem in Bodhi where an update's karma isn't
> reset to 0 when it's edited, because the glibc devs sent out a fixed
> build - 11 - but it's still at -6 karma. Still, the process works!
Well, just for the record, that change doesn't really address my
complaint. It fixes the problem that "#include <netdb.h>" fails,
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. I think it's also fair to wonder whether the new RPC
library is an *exact* functional substitute for the code that used to be
embedded in glibc. I guess we'll be finding that out in the field,
because for darn sure it's too late for any meaningful testing of
dependent packages to be happening for F15.
I don't (think I) own any packages that depend on RPC functionality,
so it's no skin off my nose if this goes through. But the folks who
do own or use such packages ought to be pretty concerned.
regards, tom lane
More information about the devel