Preparing for a point release

[Richard Laager]

[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