Bug#1014735: rpcsvc-proto: The /usr/include/rpc/* files is not included
Hi,
On 2022-07-11 22:18, Magnus Danielson wrote:
> Hi,
>
> On 7/11/22 18:30, Aurelien Jarno wrote:
> > control: tag -1 + moreinfo
> >
> > Hi,
> >
> > On 2022-07-11 02:46, Magnus Danielson wrote:
> > > Package: rpcsvc-proto
> > > Version: 1.4.2-4
> > > Severity: grave
> > > Justification: renders package unusable
> > rpcsvc-proto is used to build many packages in Debian, so I doubt it is
> > completely unusable.
> Fair enough, but for my purpose it failed completely. Of the options given
> by text in recommended tool reportbug this was closest to my experienced
> situation.
> >
> > > Dear Maintainer,
> > >
> > > Template answers first, for your convenience.
> > >
> > > * What led up to the situation?
> > >
> > > Rebuilding an application using rpcgen.
> > >
> > > * What exactly did you do (or not do) that was effective (or
> > > ineffective)?
> > >
> > > Run rpcgen, then tried to compile the produced files.
> > >
> > > * What was the outcome of this action?
> > >
> > > Any of the /usr/include/rpc/* header-files referenced such as
> > > #include <rpc/rpc.h>
> > > etc. fail to include, all the related definitions missing causes large
> > > amount
> > > of compile errors.
> > Could you please give me more details about the issue? Ideally copy and
> > paste the error message.
> make
> rpcgen core.x
> gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -g -O2 -c core_svc.c
> In file included from core_svc.c:6:
> core.h:9:10: fatal error: rpc/rpc.h: No such file or directory
> 9 | #include <rpc/rpc.h>
> | ^~~~~~~~~~~
> compilation terminated.
> make: *** [Makefile:514: core_svc.o] Error 1
>
> So, here rpcgen process the core.x, outputting core_clnt.c, core_svc.c,
> core_xdr.c and core.h.
Ok, so that's definitely the issue of the SunRPC removal from glibc.
> The next step is to compile these, and for the case of core_svc.c this fails
> because
>
> #include <rpc/rpc.h>
>
> which is generated by rpcgen (there is no such reference in core.x) and thus
> needed by users for rpcgen.
>
> I think it is fair to assume that when using rpcgen, the associated
> headerfiles needed to compile is either directly or indirectly in the
> package (or dependencies of the package).
> > My guess is that your problem is not related to rpcsvc-proto itself
> > which just provides rpcgen and related header files, but with the
> > removal of the SunRPC implementation for glibc. You need to switch to
> > the TI RPC implementation instead (using the libtirpc-dev package).
>
> Which does not work out, since rpcgen does generate the dependence to
> /usr/include/rpc/* and the installed libtirpc-dev delivers the files in
> /usr/include/tirpc/rpc/* so despite being installed, gcc does not find it,
> and the rpcgen produces files that does not compile.
Given the SunRPC library has been removed from glibc, you definitely
need to use pkg-config to get the correct link time flags to link
your code against libtirpc. Therefore changes are needed to your
project, whether you want it or not. You can therefore do the same
changes for the includes.
There are multiple compatible RPC libraries (which actually predates the
SunRPC removal), and users are able to select the one they prefer by
using the correct include and link flags.
Note that most open source projects have already been updated to
automatically switch to an alternative RPC implementation since the
first distribution removed the SunRPC support more than 4 years ago (at
this time this was still an opt-in on the glibc side).
> > > * What outcome did you expect instead?
> > >
> > > Nice compile as headerfiles is found.
> > >
> > > This is most likely a consequence of repackaging the rpc-part. Looking back
> > > at
> > > the stable version of libc6 the header files is there in libc6-dev, but for
> > > testing and unstable they are not. I expect that using these this would
> > > work.
> > > If the headerfiles is in another package, dependence on that should be in
> > > place.
> > The files that are removed from libc6-dev are the ones related to the
> > removed SunRPC implementation. libc6-dev (indirectly) depends on
> > libtirpc3-dev so the replacement header files should be available on
> > your system. That said it is not a one to one replacement, so you need
> > to use pkgconfig to get the compile and link flags.
>
> Which is documented where for this change?
The changes is documented on the Debian side in changelog.Debian.gz and
on the upstream side in NEW.gz. That said, I agree that I failed to
properly document the changes with details instructions about how to
convert existing code in the NEWS.Debian.gz file.
> The repackaging caused generated code that did work fail to work. It seems
Just to be clear, this is not a repackaging. This is a *removal* of the
SunRPC support from glibc. The TI RPC library was already packaged in
Debian, and we just provided support for rpcgen (through the
rpcsvc-proto fork). The other alternative would have to just remove
anything related to RPC.
> that rpcgen is in the wrong package so that it is not managed alongside the
> header-files that successful use of the workflow. If you only depend on the
> other headerfiles then you see no problem, but for me using the rpcgen tool
> to generate the code for the parser I depend on these header files that is
> not matching up to where they get elsewhere delivered. One way to resolve
> this would be to have the libtirpc-dev move its header files now that
> libc6-dev does not deliver them and neither does rpcsvc-proto. The rpcgen
> tool should probably be included into the libtirpc-dev rather than
> rpcsvc-proto for best coordination.
>
> Never the less, the pieces does not fit as result of this change. Usually
> the package-maintainers re-arrange things under the hood such that normal
> users do not really see the changes. That did not line up well here.
You are too much focused on header files, and you do not see the big
picture. Even if after fixing the headers as you suggest, your code will
fail to link properly if you don't get the correct link flag from
pkg-config.
> I do not mind updating my code with pkg-config, trouble is that I now need
> to specify specifically tirpc, which I did not know about was the new
> library for the headers, rather than the generic rpc or similar. So also
> pkg-config fails to transition silently the baton in this case. So
> pkg-config unfortunately does not solve the main problem that is usually
> hidden by package maintainance, to change and alter things without
> disturbing the user applications.
>
> So, I ended up requiring to know much more about how things changed
> implementations and moved behind the scenes in packaging, than is usually
> and I fail to find hints in changelog for the package to indicate this.
As said above, this probably lacks some documentation on the package
side about how to update existing code.
> > > Package-testing should actually include a dummy-application that generates
> > > through rpcgen and then compiles it successfully. Then this error would be
> > > caught. Another approach would be to check that the same header files gets
> > > installed from previous packaging and new packaging. Both methods would be
> > > recommended to create fail-safes and quick turn-around for package
> > > maintainers.
> > Don't hesitate to provide a patch doing that.
>
> For the record, I'm using the core.x out of the VXI11 standard, that is
> publically available, and do rpcgen for that. I expected that the package
> providing rpcgen either had header files or dependencies to header files
> such that generated code compiles. Turns out that in this case one needs
> additional specifics how the Debian packaging was changed. I could trivially
> provide a test-case that attempts to build the code, but as it is altered to
> know about tirpc it would fail to be representative of normal user usage.
I disagree there. Using tirpc (or another alternative) is now mandatory,
so it would not hurt using that in a simple example.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: