This is the mail archive of the libc-alpha@sourceware.org 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: Flatten sysdeps/unix/bsd/bsd4.4 into sysdeps/unix/bsd


On Wed, 9 May 2012, Roland McGrath wrote:

> I don't think this should be committed until the build has been actually
> tested on Hurd--even if that requires waiting until we've merged in more
> pending Hurd patches.

I think that's a false dependency, and I think we need to take more care 
to avoid introducing such dependencies when reviewing patches.  We should 
whenever reasonable try to work out ways in which vaguely related changes 
can go in in any order - record the desire for some enhancement (in this 
case, functional Hurd support) somewhere, in Bugzilla or on the wiki, yes, 
so it's not lost, but let in patches that improve one area without making 
things actually worse in another.

The only part of this patch with the slightest Hurd relevance is a 
one-line mechanical change

-unix/bsd/bsd4.4
+unix/bsd

and all the other parts are (a) file renames, (b) a merge of syscalls.list 
files that no supported system uses at all and (c) a change to a path in a 
#include in sysdeps/unix/sysv/linux/wait3.c.

I'd be glad to see a pile of hundreds of Hurd patches going in now on the 
basis that (i) they are in practice in use on Hurd systems, (ii) they 
don't appear to make things any worse on Hurd and clearly don't affect 
non-Hurd and (iii) they apply cleanly to current sources.  I don't believe 
any other changes should be considered to depend on such Hurd changes.

-- 
Joseph S. Myers
joseph@codesourcery.com


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