| 1 |
On Sunday 19 January 2014 13:07:24 Robin H. Johnson wrote: |
| 2 |
> On Sun, Jan 19, 2014 at 05:52:48AM -0500, Mike Frysinger wrote: |
| 3 |
> > with glibc-2.17 in stable now and glibc-2.19 release in like ~2 weeks, |
| 4 |
> > glibc 2.18 is heading to ~arch. there's been very little reported |
| 5 |
> > breakage reported thus far ... i hope it's because there isn't any vs |
| 6 |
> > people aren't using it. so if people want to try it out ahead of time, |
| 7 |
> > that'd be nice. |
| 8 |
> |
| 9 |
> What ever happened with the rpc/libtirpc changes? |
| 10 |
|
| 11 |
unfortunately libtirpc isn't feature complete with glibc. so upstream glibc |
| 12 |
reverted the rpc removal and made it into a configure time flag which Gentoo has |
| 13 |
enabled (i.e. we ship rpc headers/linkable symbols). which is why the bug |
| 14 |
onslaught died down. |
| 15 |
|
| 16 |
this doesn't preclude anyone from switching their package today to libtirpc; |
| 17 |
there are a good number of packages where the functionality it provides is |
| 18 |
sufficient. in fact, you generally want to do that: |
| 19 |
- you'll get IPv6 support (which glibc refuses to add) |
| 20 |
- it'll make packages work on other C libraries (like uClibc) |
| 21 |
- will let us stop enabling rpc functionality in glibc (we want) |
| 22 |
- other extensions being added to libtirpc? |
| 23 |
|
| 24 |
we still have the tracker open: |
| 25 |
https://bugs.gentoo.org/381391 |
| 26 |
|
| 27 |
> Will packages that used RPC headers from glibc need more changes, and if |
| 28 |
> so, what? |
| 29 |
|
| 30 |
the idea was to make libtirpc have general feature parity with glibc. there's |
| 31 |
very few people working on this upstream though (the few maintainers are |
| 32 |
common NFS peeps so they tend to focus more on that). still, some |
| 33 |
functionality is being added slowly. |
| 34 |
-mike |
Archives