Old cruft

[Gary E. Miller]

Yo Hal!

On Fri, 08 Dec 2017 18:24:36 -0800
Hal Murray <hmurray at megapathdsl.net> wrote:

> > I assuming you did a test of the debian package install, and that
> > properly installed into:
> >     /usr/local/lib/python2.7/dist-packages
> > Then you did a native NTPsec install, and that properly installed
> > here: /usr/local/lib/python2.7/dist-packages
> > Are my assumptions correct?  If so, everything worked as it
> > should.   
> 
> I don't know what a "debian package install" is.

Sorry, not being a Debian guy, my terminology is surely non-standard.
I mean cases like:

    ~ # dpkg -i XXXX.deb

    ~ # apt-get install XXXX

Or any of the other Debian style install tools.  They go into
dist-tools.  They install, mostly, into Debian specific dist-packages.

The NTPsec package, from our git head, or tarball, should install into
the Python standard site-packages.  Ignoring, for now, the many places
there may be pythonX.Y/site-packages.

> I've been using ./waf install for ages.

Ditto.  And until recently, as shown by your orphan .so, it was
installing properly into pythonX.Y/site-packages, and telling the user
to properly set PYTHONPATH.  Juat as Python upstream tells us to.

By Debian rules, ulness you do some sort of over-ride, '.waf install'
should never, ever, install into dist-packages.

Debian rules, not mine.  Somehow that got recently broken.

>  As our install recipe
> changes where it installs things, it sometimes leaves previous stuff
> in old places.  After a while, the older stuff stops working and I
> have to track it down.  I call that old stuff cruft.

And our default install recipse was not broken, it is the recent changes
that are broken!  We need to revert to the Debian, and Python, approved
locations: pythonX.Y/site-packages.

Debian came up with dist-packages precisely because they got sick and
tire of user installs being installed ovwer the top of distro, and
distro mediated (pip), installs.

> The big picture is I'm currently trying to sanity check Richard's
> local.pth recipe after applying his install patch.

Yeah, sorry, I admit to have missed a lot of stuff, both recently,
and broken patches from September.

So, forgive my tardiness, can you explain local.pth a bit?

Is it only run when installing from a .deb?

Is it only run when creating a .deb?

Is it run when './waf --install' is executed?

If we are talking the ./waf case, then we got a ton of concerns....

> It's working on Fedora but breaks on Debian.  See another message in
> the pipeline.

I'll keep digging, but with you going forward, and me backward, it
may take a while.  Oh, and don't forget, Gentoo got slightly broken, so
we got way too many unrelated things getting mushed together...

This is why we need to leave distro specific installs to the distro people.

Every authoritative source says, if we let the user install
from our tar ball, by default (at least on UNIX), it
needs to go in /usr/local/lib/pythonX.Y/site-packages or
~USER/.local/lib/pythonX.Y/site-packages

The distros install they way they do, direct user installs from source
go into site-packages.

They do their thing, we help distros do their thing, but otherwise we do
the standard thing for user source install that intentionally does not
step on the distro install.

So, if you are doing a basic './waf install', as root, it should be
installed in /usr/local/libpythonX.Y/site-packages and leave anything
installed by Debian, or Debian tools, alone, and unmolested, in their
own, private, dist-packages.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20171208/7f9dc79e/attachment.bin>