[OE-core] [PATCH 1/3] libtirpc: respin patches

[Khem Raj]

> On Mar 16, 2015, at 9:37 AM, Bernhard Reutner-Fischer <rep.dot.nop at gmail.com> wrote:
> 
> On 16 March 2015 at 17:26, Burton, Ross <ross.burton at intel.com> wrote:
>> 
>> On 16 March 2015 at 18:24, Khem Raj <raj.khem at 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? :)

patches are fine. I was merely pointing on the sweeping statement regarding patches should be always libc-independent.

> 
> thanks,