Fix for Python library path problem

[Fred Wright]

On Wed, 27 Sep 2017, Fred Wright wrote:
> On Wed, 27 Sep 2017, Eric S. Raymond via devel wrote:
>
> > I've pushed a fix for Fred Wright's FixConfig class that seems to
> > solve the problem of incorrect Python library locations.
> >
> > I tested it with no --prefix option and with --prefix=/usr,
> > using install --destdir=/tmp/ntp.
> >
> > Gary, please verify that this addresses your FHS concerns.
> >
> > Fred, please tell me if you think this is broken in some obscure way.
>
> I'm not sure about "obscure", but if the result isn't in sys.path, then
> it's back to the same old problem.

FYI, I just took a look at sys.path on the three Linuces I have here
(Ubuntu, CentOS, and Fedora), and none of them has a single entry with
"local" as part of the path.

> Looking at the waf change that introduced the trouble, it looks like it
> was mainly motivated by wanting to allow --prefix to influence the results
> (even though one can always supply --pythondir and --pythonarchdir), and
> they simply caused the no --prefix case to pas the default prefix instead
> of nothing, perhaps without realizing how this screws up the result.
>
> AFAICT, Python simply doesn't follow FHS on Linux.  It may have the
> attitude that the fact that the paths have "pythonX.Y" in them makes them
> "owned" by Python, and hence exempt from the usual FHS rules.  Whether one
> agrees with that philosophy or not, it's the way Python is set up (on
> Linux, anyway), and going against it can be expected to cause trouble.
>
> Take a look at the "non-FHS-compliant" Python library location on your
> system, and see how many *other* packages are being installed there.
> *Everyone* is going with Python rather than FHS on this issue, and if you
> want it fixed, you should convince the Python folks (or whoever configures
> the Linux Python installs) to fix it.
>
> Fred Wright
>