Alan Coopersmith wrote: > Roland Mainz wrote: > > Switching ksh93 on OS/Net to use |posix_spawn()| should therefore happen > > after the initial putback, otherwise we have to handle the difference > > somehow else, making the backport much more compliciated (unless the > > change to |posix_spawn()| gets backported, too (which will be tricky > > since the feature patch for ksh93 would then depend on a specific libc > > update... oh fun... ;-( )). > > You think that's fun? Try unraveling the tight web of interconsolidation > interdependencies that backporting Trusted Extensions to an update required. > Making ksh93 depend on a libc patch is trivial. > > Of course, since this is all about an enhancement, and the project will still > be delivering to it's ARC approved spec without it, I don't think it should > be a dependency for ksh93 integration that you do anything more than file a > bug > so the libc team knows there's an issue (and if there is a hole in the spec > of the POSIX standard, explain it to Don so that he can take it to the POSIX > committee to fix the next rev of the POSIX spec).
Ok... it's already on my ToDo list... ... note that there are more things for which bugs need to be filed... I guess lots of consolidations will have much "fun" with the ksh93 putback... for example the compiler people will have their "fun" with the sh/streval.c issue on AMD64, the dbx people will have to look after the problem why dbx dies horribly at the first sight of libast's custom memory allocator etc. etc. ... I guess the ksh93 integration will unearth lots of issues... ;-/ ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
