Now that the RPC headers are gone from glibc, libtirpc-devel could provide them in /usr/include/rpc. /usr/include/tirpc should be kept as a symbolic link. I think it is better to make the tirpc subdirectory the symbolic link because there is a slightly higher likelihood that other packages install files into /usr/include/rpc, although there are currently no such packages in Fedora. libtirpc-devel needs to add this: Conflicts: glibc-headers < 2.26.9000-35
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
(In reply to Florian Weimer from comment #0) > Now that the RPC headers are gone from glibc, libtirpc-devel could provide > them in /usr/include/rpc. /usr/include/tirpc should be kept as a symbolic > link. > > I think it is better to make the tirpc subdirectory the symbolic link > because there is a slightly higher likelihood that other packages install > files into /usr/include/rpc, although there are currently no such packages > in Fedora. I'm a bit confused on this....Are you asking for ln -s /usr/include/rpc /usr/include/tirpc? The only problem is as of glibc-headers-2.26.9000-51 those directories have different contents: ls /usr/include/tirpc ./ ../ netconfig.h rpc/ rpcsvc/ ls /usr/include/rpc ./ ../ netdb.h > > libtirpc-devel needs to add this: > > Conflicts: glibc-headers < 2.26.9000-35 Also it appears /usr/include/rpc is still in glibc-headers-2.26.9000-51 rpm -qf /usr/include/rpc glibc-headers-2.26.9000-51.fc28.x86_64
(In reply to Steve Dickson from comment #2) > (In reply to Florian Weimer from comment #0) > > Now that the RPC headers are gone from glibc, libtirpc-devel could provide > > them in /usr/include/rpc. /usr/include/tirpc should be kept as a symbolic > > link. > > > > I think it is better to make the tirpc subdirectory the symbolic link > > because there is a slightly higher likelihood that other packages install > > files into /usr/include/rpc, although there are currently no such packages > > in Fedora. > I'm a bit confused on this....Are you asking for > ln -s /usr/include/rpc /usr/include/tirpc? > > The only problem is as of glibc-headers-2.26.9000-51 > those directories have different contents: > ls /usr/include/tirpc > ./ ../ netconfig.h rpc/ rpcsvc/ > > ls /usr/include/rpc > ./ ../ netdb.h Good point. So you either need to install into /usr/include/rpc and provide a symlink in the opposite direction, or we need to coordinate further and move the netdb.h to a different directory. Which one do you prefer?
(In reply to Florian Weimer from comment #3) > (In reply to Steve Dickson from comment #2) > > (In reply to Florian Weimer from comment #0) > > > Now that the RPC headers are gone from glibc, libtirpc-devel could provide > > > them in /usr/include/rpc. /usr/include/tirpc should be kept as a symbolic > > > link. > > > > > > I think it is better to make the tirpc subdirectory the symbolic link > > > because there is a slightly higher likelihood that other packages install > > > files into /usr/include/rpc, although there are currently no such packages > > > in Fedora. > > I'm a bit confused on this....Are you asking for > > ln -s /usr/include/rpc /usr/include/tirpc? > > > > The only problem is as of glibc-headers-2.26.9000-51 > > those directories have different contents: > > ls /usr/include/tirpc > > ./ ../ netconfig.h rpc/ rpcsvc/ > > > > ls /usr/include/rpc > > ./ ../ netdb.h > > Good point. So you either need to install into /usr/include/rpc and provide > a symlink in the opposite direction, or we need to coordinate further and > move the netdb.h to a different directory. > > Which one do you prefer? Whatever is less destructive ;-) Looking at the contents of netdb.h it extern routines that I'm assuming are still in glibc, I know they are not in libtirpc... so why should libtirpc be installing netdb.h in the first place?
I would move the declarations from <rpc/netb.h> into <netdb.h>, and libtirpc could then install a <rpc/netdb.h> file which just contains: #include <netdb.h> Does this make sense?
(In reply to Florian Weimer from comment #5) > I would move the declarations from <rpc/netb.h> into <netdb.h>, and libtirpc > could then install a <rpc/netdb.h> file which just contains: > > #include <netdb.h> > > Does this make sense? Sorry but no... What I don't understand is why a library would install a header file that contain externs for routines it does not have? There are 60 externs of routines in netdb.h. Is all that going to be moved out of glibc?
I'm not following. We are going to remove <rpc/netdb.h> from glibc, move those declarations into <netdb.h>, and libtirpc can ship a compatibility header in place of of <rpc/netdb.h> which simply includes <netdb.h>. It does not need to repeat any declarations.
(In reply to Florian Weimer from comment #7) > I'm not following. I'm trying ;-) >We are going to remove <rpc/netdb.h> from glibc, Got it... > move those declarations into <netdb.h>, So the code is staying in glibc.. got that too... > and libtirpc can ship a compatibility header in > place of of <rpc/netdb.h> which simply includes <netdb.h>. I see this logic but as of today libtirpc-devel does not install anything into /usr/include/rpc. All the header files go under /usr/include/tirpc. So you are asking that libtirpc-devel install an new file called netdb.h under /usr/include/rpc that contains a '#include <netdb.h>' Or are you asking a new netdb.h header that contains the above include to be install under /usr/include/tirpc/rpc then create a symlink like ln -s /usr/include/tirpc/rpc /usr/include/rpc In both cause libtirpc-devel will be taking over the ownership of /usr/include/rpc.
(In reply to Steve Dickson from comment #8) > I see this logic but as of today libtirpc-devel does not > install anything into /usr/include/rpc. All the header > files go under /usr/include/tirpc. Understood. > So you are asking that libtirpc-devel install an > new file called netdb.h under /usr/include/rpc > that contains a '#include <netdb.h>' > > Or are you asking a new netdb.h header that > contains the above include to be install > under /usr/include/tirpc/rpc then > create a symlink like > ln -s /usr/include/tirpc/rpc /usr/include/rpc Both approaches work. > In both cause libtirpc-devel will be taking over > the ownership of /usr/include/rpc. This is the key point, yes. The idea was that if the tirpc headers are substantially compatible, they should be installed under /usr/include/rpc, so that applications need fewer changes for the switch to tirpc. However, I'm not convinced anymore that this is such a great idea because the RPC interfaces *are* different. But perhaps we can do it for the XDR interfaces?
What the story with /usr/include/rpc and /usr/include/rpc/netdb.h both are still owned by glibc-headers fedora# rpm -qf /usr/include/rpc glibc-headers-2.27.9000-7.fc29.x86_64 fedora# rpm -qf /usr/include/rpc/netdb.h glibc-headers-2.27.9000-7.fc29.x86_64 f28# rpm -qf /usr/include/rpc glibc-headers-2.27-8.fc28.x86_64 f28# rpm -qf /usr/include/rpc/netdb.h glibc-headers-2.27-8.fc28.x86_64 I'm not sure how to move forward
/usr/include/rpc/netdb.h provides NSS-related functionality which is only in glibc, not in libtirpc. It could theoretically be used without RPC, too. So … considering that libtirpc-devel has a .pc file, I'm no longer sure if this switch is such a good idea. Maybe we should tell developers instead to use pkg-config, and close this bug?
Here is how I handled this CFLAGS+=`pkg-config --cflags libtirpc` LIBS=`pkg-config --libs libtirpc`
(In reply to Florian Weimer from comment #11) > /usr/include/rpc/netdb.h provides NSS-related functionality which is only in > glibc, not in libtirpc. It could theoretically be used without RPC, too. > > So … considering that libtirpc-devel has a .pc file, I'm no longer sure if > this switch is such a good idea. Maybe we should tell developers instead to > use pkg-config, and close this bug? I agree...