On 16 March 2015 at 17:26, Burton, Ross <ross.bur...@intel.com> wrote:
>
> On 16 March 2015 at 18:24, Khem Raj <raj.k...@gmail.com> 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? :)
thanks,
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
