This is the mail archive of the
mailing list for the glibc project.
Re: How to do the sunrpc revert?
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Allan McRae <allan at archlinux dot org>
- Cc: Andreas Jaeger <aj at suse dot com>, libc-alpha at sourceware dot org
- Date: Wed, 9 May 2012 09:37:24 -0400
- Subject: Re: How to do the sunrpc revert?
- References: <firstname.lastname@example.org><4FAA3AEE.email@example.com>
On Wed, May 9, 2012 at 5:37 AM, Allan McRae <firstname.lastname@example.org> wrote:
> On 09/05/12 18:17, Andreas Jaeger wrote:
>> I looked briefly at the sunrpc changes while waiting for more people to give
>> their "Yes, do it" ;).
>> Fedora and openSUSE (not checked others) use a very simple patch (attached as
>> glibc2.14-revert-sunrpc-removal.patch) that works but is more of a hack, e.g.
>> it does the following in include/libc-symbols.h:
>> -# define libc_hidden_nolink(name, version) hidden_nolink (name, libc, version)
>> +# define libc_hidden_nolink(name, version) hidden_def (name)
>> The full removal patch (attached as sunrpc-removal.patch) is rather large and
>> contains also whitespace changes which I propose not to revert.
>> Should we do a full revert of the patch or use the simple patch - or is there
>> some middle ground?
>> If we do a revert, what should not be reverted besides copyright lines
>> and whitespace changes?
>> I consider the simple patch a bit too hackish.
> It might be hackish, but it has the advantage of being quite well tested
> (I'll add Arch and Gentoo to the list of distros that use the same
> patch) which with less than a week until 2.16 freeze would be good.
> Also, it is very small so will be easy to revert when this really can be
As the 2.16 release manager I would agree with Allan here.
* Apply hack to trunk.
* Release 2.16 with well tested hack.
* File a bug in with milestone=2.17.
* Revert it fully after 2.16 branches.
I know that makes your life a little more complicated but it's
certainly less risky.