Bug#1014735: rpcsvc-proto: The /usr/include/rpc/* files is not included
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.
> 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.
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).
> * 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.
> 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.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: