bump libtirpc to 1.0.1
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Buildroot] [PATCH 0/2] bump libtirpc to 1.0.1
Quoted 6 lines · Thomas Petazzoni
Dear Peter Rosin,
Quoted 2 lines · Peter Rosin
I'd like to bump libtirpc to 1.0.1. However there is an api incompatibility introduced in 0.3.2 which requires a patch to rpcbind, which I took from
oops, introduced in -> introduced since
Quoted 7 lines
Quoted 3 lines
upstream. The rpcbind patch make rpcbind work with either tirpc 0.3.2 or 1.0.1, so I added that patch first in the series even if it might seem backwards.
Thanks for those patches. Is rpcbind the only user of libtirpc that is affected by the API change ?
Thomas
Good question...
I think so, but who knows? Personally I would have kept libtirpc compatible (that was a possibility), but upstream decided to make the switch since they didn't know of any users and wanted to get in line with other tirpc implementations. Then this regression in rpcbind was discovered, which was rather close to home...
The changed interface was thought to be only for adding custom authenticators to RPC, something that is thought to be extremely specialized, but the rpcbind use looks like a workaround for problems getting replies out when using libtirpc somewhat strangely (again, I don't know rpcbind and have only had a cursory look at the code). If a package is using libtirpc normally and do no strange things (unlike rpcbind, which probably is quite special) and don't add its own application specific RPC authenticator, it should not be affected. But as I said, who knows?
Fixing breakage in libtirpc users should be straightforward if any come up, and another possibility is to add a patch to revert the final change that removed the old interface. However, that revert is touching core areas in a number of places and is probably not fun to keep around for any length of time. It can be added if needed, is that good enough?
I can only find the upstream discussion in the mail archive at sf, which has a rather sucky interface, sorry.
Cheers,
Peter