[Replying to lots of different people, slightly out-of-order.] On 12/05/2017 09:52 AM, Eric S. Raymond via devel wrote: > I'm not clear why we care about the pip cases.
I agree. If this matters, it can always be addressed later. On 12/05/2017 09:17 AM, Ian Bruene via devel wrote: > Distro Install: /usr/lib/python<ver>/dist-packages > Distro Install, pip: /usr/lib/python<ver>/site-packages > User Install, pip: /usr/local/python<ver>/dist-packages > User Install: /usr/local/python<ver>/site-packages These aren't quite correct. I'm not sure about the convention for pip. Even if the pip thing is correct, the two "User" installs are backwards. dist-packages is a Debian-ism: https://wiki.debian.org/Python#Deviations_from_upstream >From my reading of that wiki page, the distro-packaged Python uses dist-packages whenever stock Python would use site-packages. This way, if you install the distro Python package *and* Python from source, you can install modules for each and they don't conflict. Modules for the distro-packaged Python go in dist-packages, and modules for the source-built Python go in site-packages. Debian, distro Python, prefix = /usr (e.g. the ntpsec package): /usr/lib/python<ver>/dist-packages Debian, source Python, prefix = /usr (e.g. not a great idea): /usr/lib/python<ver>/site-packages Debian, distro Python, prefix = /usr/local (e.g. ntpsec from source): /usr/local/lib/python<ver>/dist-packages Debian, source Python, prefix = /usr/local (e.g. both from source): /usr/local/lib/python<ver>/site-packages Other distros, assuming they don't patch in dist-packages, have only site-packages. non-Debian, prefix=/usr (e.g. ntpsec package): /usr/lib/python<ver>/site-packages non-Debian, prefix=/usr/local (e.g. ntpsec from source): /usr/local/lib/python<ver>/site-packages >From ianbrunene later on IRC: import distutils.sysconfig print(distutils.sysconfig.get_python_lib( standard_lib=0, prefix='/usr/local')); Instead of the hard-coded '/usr/local', pass in whatever --prefix was passed to waf. On 12/05/2017 10:32 PM, Eric S. Raymond via devel wrote: > At least in RPM-land, they like to use the package's own make install > when possible. I sin't know about Debian packaging. Yes, it's ideal to use upstream's make install. Obviously, we packagers can patch as necessary. I get the impression that Debian packages, in general, tend to do more patching than RPMs. On 12/05/2017 11:00 PM, Gary E. Miller via devel wrote: > They say DO NOT install the packages as root. So installing > into /usr is just not gonna be possible. The typical approach to this, on Debian, amounts to: ./configure --prefix=debian/tmp/usr make make install In RPMs, it's something like this: # %{buildroot} is expanded by the RPM build process. ./configure --prefix=%{buildroot}/usr make make install On 12/05/2017 11:11 PM, Hal Murray via devel wrote: > How do they use it? Do they actually do a "make install" in the build > environment Yes. But note that prefix points to $some_tmp/usr, not real /usr. > Using our install step would require including waf with the package > and dragging in python, somehow. That seems unlikely. waf is already necessary to get ntpsec to *build*. waf is shipped in the release tarball. Debian, in particular, doesn't like waf being in the release tarball. It is considered non-free, as it's a big blob, unfriendly to modification. Debian requires that waf be unpacked: https://wiki.debian.org/UnpackWaf This is all settled in the Debian ntpsec package I uploaded, and shouldn't be of significant concern to upstream ntpsec. It might have been an argument against choosing waf in the first place, but that's in the past now. -- Richard _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel