This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cross-rpcgen patch, version 6

On 05/09/2012 08:09 PM, Roland McGrath wrote:
On Tue, May 8, 2012 at 9:40 AM, Andreas Jaeger<> wrote:
I wouldn't mind reverting the removal in glibc and including sunrpc again
since there's no replacement yet. ;-(

I believe that this should be done sooner rather than later e.g. 2.16 or 2.17 timeframe.

My feeling is that it was a premature removal. We should have had
overlap before removing the code from glibc.

I do agree that it was done hastily and could have been handled better. But it's my view that what's done is done and we should move forward rather than backward. The distribution maintainers who have undone the change in their forks don't have any trouble continuing to do so for another release.

They won't have - unless somebody starts cleaning up the code even more. If we keep the status quo, we should have an agreement not to break the situation even further.

Since what we're talking about is getting TI-RPC to be able to do what code
with related lineage was capable of 25 years ago, I cannot believe that the
work involved there is all that much.  The fact that nobody can be bothered
to do it by a year later is just more evidence that nobody really cares
about sunrpc, and that says to me we should be straining in the direction
of dropping it rather than in the direction of retaining API support for
something so obsolete and unloved.

AFAIK the two large rpc users are NFS and NIS. TI-RPC is used today by the NFSv4 code but not usable for NIS at all. And NIS is IMO fading out as well but still in use... I even suggested dropping NIS but didn't succeed ;-(

If the absence is really so much trouble for anyone, that should be impetus
for them to contribute the work TI-RPC needs to do its job adequately.
I'm clearly in the minority here and I'm not going to make a big stink
about it, but I firmly think that the notion of reverting the removal is
the wrong thing to do.

The problem is that everybody is patching it in. We could add a configure option to enable building against it - that would send the message out as well that its obsolete.

 Andreas Jaeger aj@{,} Twitter/Identica: jaegerandi
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]