upstream URL https://github.com/nfs-ganesha/ntirpc and https://github.com/nfs-ganesha/nfs-ganesha
A package under review[1] — nfs-ganesha — statically links with libntirpc.a. (A stand-alone build of libntirpc does not produce a shared library at this time.)
The nfs-ganesha package does not ship (bundle) the library in the RPM, it is only bundled in the sense that it is built as part of the larger build of the nfs-ganesha package — the nfs-ganesha binary is statically linked with it, then it is discarded.
As the nfs-ganesha nfs daemon is statically linked with all of its own libraries (including libntirpc) it's clear that there is little or no value to be obtained by theoretically being able to install a newer, unbundled version of libntirpc. It should go without saying, when an unbundled version of libntirpc becomes available, a new version of nfs-ganesha that uses it will undoubtedly be released at the same time.
libntirpc has diverged significantly from libtirpc; the changes are incompatible with upstream libtirpc.
(lib)ntirpc is a git submodule of nfs-ganesha. ntirpc is licensed with a BSD 3 clause copyright (versus the rest of nfs-ganesha, which is LGPLv3+) and is in git submodule solely (AFAIK) to provide different ACLs to different maintainers, otherwise I imagine it would be in the nfs-ganesha git repo directly.
The long term plan is to package libntirpc once the interfaces stabilize, but for now it is tightly coupled to nfs-ganesha while the interfaces are in a state of flux; it's not suitable for consumption by other packages at this time.
https://bugzilla.redhat.com/show_bug.cgi?id=1026337
... otherwise I imagine it would be in the nfs-ganesha git repo directly.
s/b
otherwise I imagine it would be in the nfs-ganesha source code directly.
the contents of the RPM {{{ % rpm -q --list -p RPMS/x86_64/nfs-ganesha-2.0.0-0.rc3.fc19.x86_64.rpm /usr/bin/ganesha.nfsd /usr/bin/ganestat.pl /usr/lib/systemd/system/nfs-ganesha.service /usr/lib64/ganesha /usr/lib64/ganesha/libfsalgpfs.so.4 /usr/lib64/ganesha/libfsalgpfs.so.4.2.0 /usr/lib64/ganesha/libfsalnull.so.4 /usr/lib64/ganesha/libfsalnull.so.4.2.0 /usr/lib64/ganesha/libfsalproxy.so.4 /usr/lib64/ganesha/libfsalproxy.so.4.2.0 /usr/lib64/ganesha/libfsalvfs.so.4 /usr/lib64/ganesha/libfsalvfs.so.4.2.0 /usr/share/doc/nfs-ganesha /usr/share/doc/nfs-ganesha/ChangeLog /usr/share/doc/nfs-ganesha/LICENSE.txt /usr/share/doc/nfs-ganesha/TODO % }}}
I talked with Kaleb about this, I think that this exception makes the most sense right now based on the tight coupling of nfs-ganesha and libntirpc and the instability of the APIs in that library right now.
In the future, libntirpc may well become its own project separate from nfs-ganesha, but at the moment, it makes little sense to block this exception in my opinion.
updated to RC4, including fetch of ntiprc from upstream instead of kkeithle.fedorapeople.org, contents of the rpm are unchanged:
{{{ %rpm -q --list -p RPMS/x86_64/nfs-ganesha-2.0.0-0.rc4.fc19.x86_64.rpm /usr/bin/ganesha.nfsd /usr/bin/ganestat.pl /usr/lib/systemd/system/nfs-ganesha.service /usr/lib64/ganesha /usr/lib64/ganesha/libfsalgpfs.so.4 /usr/lib64/ganesha/libfsalgpfs.so.4.2.0 /usr/lib64/ganesha/libfsalnull.so.4 /usr/lib64/ganesha/libfsalnull.so.4.2.0 /usr/lib64/ganesha/libfsalproxy.so.4 /usr/lib64/ganesha/libfsalproxy.so.4.2.0 /usr/lib64/ganesha/libfsalvfs.so.4 /usr/lib64/ganesha/libfsalvfs.so.4.2.0 /usr/share/doc/nfs-ganesha /usr/share/doc/nfs-ganesha/ChangeLog /usr/share/doc/nfs-ganesha/LICENSE.txt /usr/share/doc/nfs-ganesha/TODO % }}}
developers think ntirpc will be stable enough for stand-alone packaging as a sharedlib sometime in 2014.
We started voting on a temporary bundling exception for this today:
Need one more +1 to pass.
I'd like to know why the library was forked before allowing an exception. Were there any attempts to push the ganesha-related changes to libtirpc upstream?
developers say: It's forked because the upstream has no callback support, and we've had to make incompatible changes to support better multithreading. And we'd like, ideally, to redo much of the API to make it better.
developers add: the main point is that we've made incompatible api changes, mostly for mt safety, but also for enhanced features in encoder/decoders, data placement, and so on. Since most applications consuming libtirpc don't need these features, it doesn't make a great deal of sense to me try to force change on them. Those that do will can self-select for the new library when it's api is well defined. This seemed politically expedient too, since while steved liked a lot of these changes, Chuck Lever believes that libtirpc's api is frozen (which as above, is a non-starter).
From the last comment I understand this was discussed and while one libtirpc developer liked the changes (Steve Dickson?), another (Chuck Lever) was against any API changes. Is that correct? If yes, then I'm satisfied with the answer and +1 to the exception.
Is that correct?
... steved liked a lot of these changes, Chuck Lever believes that libtirpc's api is frozen...
??? Seems like that's what is being claimed. I'm not sure what you're looking for?
I think that Rathann would vote +1 based on the last comments but to be sure we asked for votes at today's meeting and got a fifth +1 there.
Temporary bundling exception for bundled(libntirpc) until after Fedora 23 approved: (+1:5, 0:1, -1:0)
Please use virtual Provide: bundled(libntirpc)
Metadata Update from @kkeithle: - Issue assigned to toshio
Login to comment on this ticket.