This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] deprecate libnsl (Version 3)
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Thorsten Kukuk <kukuk at suse dot de>
- Cc: <libc-alpha at sourceware dot org>
- Date: Sat, 29 Oct 2016 18:18:44 +0000
- Subject: Re: [PATCH] deprecate libnsl (Version 3)
- Authentication-results: sourceware.org; auth=none
- References: <20160406094807.GA23625@suse.de> <alpine.DEB.2.10.1604061726080.19511@digraph.polyomino.org.uk> <20160408131142.GA7627@suse.de> <20160623064622.GA27378@suse.de> <20161029103834.GA1348@suse.de>
On Sat, 29 Oct 2016, Thorsten Kukuk wrote:
> Hi,
>
> since I still got no feedback about the deprecation patches
> for sunrpc and libnsl and no try was made to get it into
> the last glibc version, I assume nobody is interested in
> really deprecating this old IPv4 only code to make it easier
> for other projects and users to switch to IPv6?
Could you give the URL for the latest patch versions, and for any relevant
discussions that might indicate consensus, lack thereof or other relevant
issues, when pinging a patch (and pings should be approximately weekly,
including the URL every time, with patches updated if they no longer apply
cleanly to current sources)? Please make sure the latest version is
self-contained with a full write-up explaining it so that there's no need
to refer back to previous versions / other emails for an understanding of
the change being made and the rationale for the change and the design used
(and that it includes NEWS entries pointing to any relevant replacement
libraries for users, etc.).
I suspect there's a lack of people familiar with the code and ready to
judge desirability of the change, which makes it especially important to
have a thorough self-contained explanation of everything included with the
patch (the NEWS entries of course should have such information aimed at
people building/using glibc so it's immediately obvious where they should
go to get libnsl, libnss* etc. and what changes to their code they might
need to use such replacements).
--
Joseph S. Myers
joseph@codesourcery.com