On 01/04/2018 01:21 PM, Gary E. Miller via devel wrote:
What are these other issues?
The FHS, Gentoo, and AFAIK all distros, do not include /usr/local/XX
in any enviroment PATHs.

Ubuntu does. Did people just not usually use /usr/local/ much in the Eldar Days? That would explain it not being part of FHS but distros moving towards including it.

So, when I install NTPsec in /usr/local, I need to be sure I
have added /usr/local/XX to at least:
        PATH
        MANPATH
        PYTHONDIR

OTher things installed in /usr/local may also require adding /usr/local
to:
        INFOPATH
         PKG_CONFIG_PATH
        LD_LIBRARY_PATH

And there are more not wide used.

'Fixing' just PYTHONPATH, and ignoring the others is touching only
part of the problem.

Ooookaaayyy..... That is a much bigger problem. If what you are describing is true how is the build working /at all/ on non-Debian systems?

If anything is going into /usr by default, that is new, and very, very
bad.  That conflicts with FHS and the policy of every distro I know of.

Not by default, but if the provided paths don't show up in sys.path it does. And this is not a new problem, you came across it some time ago, but no fix has been decided on as of yet.

Yes, and also the binaries, man pages, and other things.  This is
by design, dating back to UNIX tradition in the 1970's, still embedded
firmly in the FHS, etc.

Why then did the documentation only talk about adding to PYTHONPATH?

      bad: apparently breaks inter-version seals between different
copies of NTP. But this is true of any distro with /usr/local/
      good: it doesn't bypass python versioning <--- This is a Huge
Uh, no.  Until the user sets his PATH, MANPATH, INFOPATH, PYTHONPATH, etc.
the traditional way does NOT break the NPT in /usr.

Not a particularly relevant detail; if it is used to breaks the seal. One might also say that if it isn't built it won't have bugs.

      neutral: I'll bet that this doesn't solve the specific variant
of the problem that I've encountered (a weird variant)
You only have a problem because you have not properly configured your
many PATH variables yet.

IMHO if we end up defaulting to the old method we should suggest the
user create a .pth file instead of PYTHONPATH.
I suggest we give him both options.  .pth file is not an option for
many.

PYTHONPATH is a mess for this kind of thing.
Really???  So PATH, MANPATH, INFOPATH, LD_CONFIG_PATH, etc. are somehow
easy for you, but PYTHONPATH is not easy????  This is ONE LINE in ONE
FILE.

Ok, now I have to describe the bug I encountered (yes, already filled a report upstream). On my system any version of python 3 gives a /usr/local/ install path for version "python3". But it only adds paths for "python3.<n>" under /usr/local/.

This is what I mean when I say that PYTHONPATH is a mess for this kind of thing. You can't tell it to add a path for certain versions of python only. You can tell it to use a specific path, or you can tell it to use a path with the standard subdirectories which the sys.path builder script will then add.

--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys."/ -- Andrew Ryan

/"Utopia cannot precede the Utopian. It will exist the moment we are fit to occupy it."/ -- Sophia Lamb

_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel

Reply via email to