Re: lang/python27 fails to install on Fedora 29

["David H. Gutteridge" <david%gutteridge.ca@localhost>]

On 23 Feb 2019, at 00:05:33 -0500, David J. Weller-Fahy wrote:
> * David H. Gutteridge <david%gutteridge.ca@localhost> [2019-02-22 00:57 -0500]:
> 
>     On Thu, 21 Feb 2019, at 22:09:18 -0500, David J. Weller-Fahy wrote:
> 
>         Is there a better way to determine situations where neither nis.so
>         nor nis_failed.so should be built? Or, if not, is there a way to
>         identify a system as "Fedora", rather than simply "redhat"
>         (OS_VARIANT contents on my Fedora system), and thus check for that?
> 
>         Suggestions and answers welcome - even just pointers on where to look
>         would be helpful.
> 
> 
>     I ran into this as well, but hadn't got around to doing anything about
>     it (beyond temporarily hacking the package to get it to build). It's
>     ultimately not a question of identifying a particular distro, it's a
>     matter of determining which glibc version is in use, which, I believe,
>     isn't a simple thing to do. Recent versions of glibc dropped support
>     for what Python depends on in this context.
> 
> 
> Ok, so python can no longer reliably detect a particular feature in
> glibc, which not all systems have. That's good to know, thanks.
> 
>     Fedora does still build and install nis in their Python 2.7 package;
>     they use a different means of exposing the necessary files to do so.
>     This subject in general is discussed in more than one Python bug
>     report:
> 
>     https://bugs.python.org/issue32007
>     https://bugs.python.org/issue32521
> 
>     Fedora's change set is here:    
> https://src.fedoraproject.org/rpms/python2/c/3056bfd92a4269ad8f9b57cab05af3125e87ca8c?branch=master
> 
> 
> After reading through all of these it seems like Fedora took the
> positition that removing the options from the prebuilt packages was the
> right thing to do. I also have been thinking about this from the user's
> perspective, and thought adding an option might be the least destructive
> option: something that would only take effect when activated by the
> user, but would indicate to the package how to handle nis (omit entirely
> or include per existing logic).
> 
> Do you think that would be a reasonable solution to this issue? It
> doesn't solve the problem, but I'm not sure I know how to solve it in an automated way.

Well, there's more than one way around the issue. One method (for
Fedora, anyway) is to install the libnsl2-devel and libtirpc-devel
packages. Then the build should succeed with the the pkgsrc make file
unaltered. One could argue this is a distro-specific "gotcha" that's no
different than some of the other similar considerations about needing
to install particular "devel" or "dev" distro packages of headers to
get packages to build. (Another random example that may confuse people
is that Fedora installs GCC by default, but only the C compiler, not
the C++ compiler.)

At present, the nis option isn't meant to be user-settable, so changing
that would require reworking things into options.mk. Instead of (or in
addition to) that, a check could be added to look for the header files
that Python expects to find, and act accordingly. (The Python
configuration code itself looks for rpcsvc/yp_prot.h in the include
paths it's searching.) But, again, it may make more sense just to
document somewhere the specific extra distro packages that need to be
installed on Fedora to get some pkgsrc packages to build.

Dave