Preparing for a point release

[Hal Murray]

> It is closed with, "F27 will have this issue resolved.".

I'm running on F27.

> For existing systems, there are three solutions:
...

rlaager at wiktel.com said:
> 3) Create a .pth file in the appropriate place, which is somewhere under /
> usr. There are probably existing ones: find /usr/lib*/python2.7 -name
> "*.pth" 

[murray at hgm raw]$ find /usr/ -name "*.pth" 2>/dev/null
/usr/lib64/python3.6/site-packages/abrt3.pth
[murray at hgm raw]$ 
[There were some Permission denied stuff in there]


> Given that this is fixed in the distro, I think the right trade-off is to
> recommend #3, either in documentation and/or in a warning from waf if the
> configured pythondir is not in sys.path. I would like to see the
> fix_python_config.py code removed, as it is creating new breakage. 

I agree that we should document a fix that doesn't mess up our code or 
processes.

This is only a problem for developers.  Right?  It's more than just F27.  
CentOS has it, and F26 is still supported.  (F25 too, but it goes EOL soon.  
I'm happy to ignore it, but whatever works for F26 will probably work for F26 
too.)

Where is the documentation for .pth stuff?


rlaager at wiktel.com said:
> cat > /usr/lib64/python2.7/site-packages/local.pth << EOF
> /usr/local/lib64/python2.7/site-packages
> /usr/local/lib/python2.7/site-packages
> EOF 

I think that works.  I'm going to run with it (and your patch), but it may 
take a while for me to get rid of my old PYTHONPATHs and remove stuff from 
/usr/ (without local).


-- 
These are my opinions.  I hate spam.