Preparing for a point release

Richard Laager rlaager at
Wed Dec 6 05:57:37 UTC 2017

[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:

>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):

Debian, source Python, prefix = /usr (e.g. not a great idea):

Debian, distro Python, prefix = /usr/local (e.g. ntpsec from source):

Debian, source Python, prefix = /usr/local (e.g. both from source):

Other distros, assuming they don't patch in dist-packages, have only

non-Debian, prefix=/usr (e.g. ntpsec package):

non-Debian, prefix=/usr/local (e.g. ntpsec from source):

>From ianbrunene later on IRC:
  import distutils.sysconfig
      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 install

In RPMs, it's something like this:
    # %{buildroot} is expanded by the RPM build process.
    ./configure --prefix=%{buildroot}/usr
    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:

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.


More information about the devel mailing list