Adam Williamson <awilliam@xxxxxxxxxx> 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? > [snip] > In fact, you can see this has already happened: > https://admin.fedoraproject.org/updates/glibc-2.13.90-11 > 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
