> On Mar 16, 2015, at 9:37 AM, Bernhard Reutner-Fischer <[email protected]> > wrote: > > On 16 March 2015 at 17:26, Burton, Ross <[email protected]> wrote: >> >> On 16 March 2015 at 18:24, Khem Raj <[email protected]> wrote: >>> >>> Patches are fine in this series, however I just want to set the >>> expectations right here. While having that libc-independent goal is fine. >>> Sometimes we just can not do it, since uclibc or musl >>> does not have all the features that glibc has and an app might also be >>> using it. >>> making glibc users not have those features is unfair >>> given that we have a strong mechanism of overrides in OE, it should be >>> used to this advantage. >> >> >> But these patches, which add configure options to enable/disable the >> relevant functionality and have been sent upstream - represent the ideal >> case as once they're merged won't cost us any effort in the future. > > I just disable NIS / YP for uClibc and leave glibc (or any other libc > for that matter) to do what they previously did. > libtirpc is an excellent example for this unchanged behaviour: > > src/getrpcent.c: if (!__yp_nomap && _yp_check(&d->domain)) { > > and i did not change that since first, i don't care and second, maybe > glibc-users do fun stuff to let _yp_check resolv to the proper > __yp_check, i don't know nor really care ATM. > > I think uClibc-users do not expect to have NIS support, we never > implemented Yellow Pages support since that is usually way out of > scope for those setups. > > Maybe i misread your comment, though, Khem? > Or do you refer to a glitch i introduced? If so, what did i botch? :)
patches are fine. I was merely pointing on the sweeping statement regarding patches should be always libc-independent. > > thanks, -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
