Re: deprecated sunrpc and rpc/netdb.h

[Mike Frysinger <vapier at gentoo dot org>]

On 17 Mar 2016 11:48, Thorsten Kukuk wrote:
> On Wed, Mar 16, Mike Frysinger wrote:
> > On 16 Mar 2016 15:33, Thorsten Kukuk wrote:
> > > On Wed, Mar 16, Mike Frysinger wrote:
> > > > netdb.h provides funcs to map RPC names<->ports and is only useful
> > > > to rpc related code.  if we purge sunrpc code from glibc (which we
> > > > want), then purging the netdb code too makes sense.
> > > 
> > > Correct, but how do you want to handle NSS?
> > > There is a "rpc" entry in /etc/nsswitch.conf and it doesn't
> > > make much sense to copy the whole NSS code into tirpc and
> > > similar libraries.
> > 
> > drop it from glibc too and make it an ignored keyword.  whether tirpc
> > wants to support that indirection is up to that project.
> 
> Sorry, but it is completly unrealistic, that an another
> project duplicates the glibc NSS infrastructure to support
> this. Don't forget, that another project would to closely
> follow everything glibc is doing, since there is only one
> NSS plugin, which has support for the glibc and tirpc part.
> And I'm not sure if this will really work, if this plugins
> are always loaded twice ...

i'm not suggesting they duplicate it.  maybe they don't provide
alternatives at all.  why does that matter to us ?  it's not like
other projects are really clamoring for this.

> > > And how do you want to solve the current problem of 
> > > source code breakage with the dummy rpc/netdb.h?
> > 
> > i'm not familiar with the details you're referring to.  if glibc is
> > built with --disable-obsolete-rpc, then it shouldn't install this
> > header at all.
> 
> Correct, but this would break everything which includes netdb.h,
> which is a glibc header file. I assume for this reason, the dummy
> rpc/netdb.h was introduced, but it does not solve the problem.

the only reason rpc/netdb.h exists is because glibc imported rpc
code from sun.  getrpcent & friends is not in POSIX or any other
standard.  the fact that glibc installs it today making it a "glibc
header" is kind of a pointless statement -- by that logic, every
single rpc/ header glibc installs is a "glibc header".

> If you don't want to touch every single piece of code there
> outside (and this would be the only other option I currently
> see, which would be completly incompatible to any other Unix), 
> the best solution I currently see is, that glibc continues 
> to ship rpc/netdb.h and the corresponding rpcent functions.
> Especially, as this function don't contain any SunRPC code 
> anymore, this are pure glibc macros.

this only impacts projects that use sunrpc, and that's dwindling in
numbers today.  any project that wants to keep using sunrpc has to
be updated to detect/use tirpc *regardless* of rpc/netdb.h.  if the
tirpc project includes netdb.h, then it's a solved problem.

other than fixing glibc to not install rpc/netdb.h (or any other
rpc related header) when rpc is disabled, i'm not seeing what the
fuss is about.
-mike

Attachment: signature.asc
Description: Digital signature