Preparing for a point release

[Gary E. Miller]

Yo Richard!

Uh, sorry, I've been offline with the grunge.

On Thu, 7 Dec 2017 20:22:48 -0600
Richard Laager via devel <devel at ntpsec.org> wrote:

> On 12/07/2017 03:06 PM, Fred Wright via devel wrote:
> > On Wed, 6 Dec 2017, Ian Bruene via devel wrote:
> >   
> >> For installs the only remaining problem is that for unknown
> >> reasons it sometimes doesn't follow the PREFIX when installing the
> >> python libs.  
> > 
> > There's nothing "unknown" about it.  
> 
> Actually, there is something unknown. Gary's case in #414 seems to be
> the default of prefix=/usr/local, which should be in sys.path,

sys.path?  How that that get in the mix?  I always used PYTHONPATH.

This link does imply controversy, with a slight lean to PYTHONPATH over
sys.path.

https://stackoverflow.com/questions/1893598/pythonpath-vs-sys-path

But my installer should be listening to what I tell it, not look in my
environment which I'll likely configure AFTER I install NTPsec.  And,
as you'll see reading blow, both may be totally irrelevant.

> and yet
> he is getting the python bits installed to /usr. Surely that is not
> the intended behavior, right?

And worse, SOME of my install goes in /usr, some in /usr/local.  It should
be all one, or all the other.

The goal is not one intended behavior, but to easily, and obviously, allow
for any intended behavior.

I'm a big fan of long standing tradtion, embodied in the FHS, that user
installed software goes in /usr/local.  That cleanly separates my 
experiments from the carefully curated packages from my distro.


> The default case is prefix=/usr/local, which (correct me if I'm wrong)
> works without hacks.

Sadly, recently broken.


> The distro-packaging case is to install to /usr, which (correct me if
> I'm wrong) works without hacks. For this case, keep in mind that the
> final install location is /usr, but prefix is a temporary directory.

Not always...

I'm also a big fan of Gentoo, and their supported packages.  The Gentoo
way is to download the upstream tarball, then build locally, and install
in /usr as officially installed software.

You are talking about the the easy case when you install a binary
package provided by your distribution.  The packager put the files in
the package, and the installation program (apt-get?) puts the files
in /usr.  Nothing we do affects that process.  But what we do affects
how easy it is for the packager, once for every release, to build the
binaries, and install them in a work area (/var/tmp?) so that he can
build the package.

> The only other real world case I can think of (for software generally,
> not just ntpsec), is an install to something under $HOME. These days,
> ~/.local is a standardized location, that Python supports.

OK, I'll admit, I pretty much only build on boxen where I own root.  But
that is also a pretty nice observation.

> Are there other scenarios that you personally care about, or know of
> someone that does? To be clear, I'm not interested in debating
> hypothetical scenarios that *could* exist.

I think you're getting a feel for the space.  So I'll complicate it
some more.

Look at all Debian derivatives.  Now we got 4 possible ultimate
destinations, and I'm not exactly sure I got it exactly right:

	Official Packages install .py in:
             /usr/lib/pythonX.Y/dist-packages
	PIP Packages install by system pip in:
             /usr/lib/pythonX.Y/site-packages
	User sources install .py in:
             /usr/local/lib/pythonX.Y/dist-packages
	User installed PIP installs pip packages in:
             /usr/local/lib/pythonX.Y/site-packages

We, NTPsec upstream, only control the 3rd item, but need to make it
trivial, and obvious, for a time pressed packager to get from our upstream
package what they need to make those other options easy for them to do.

> Can we drop fix_python_config and just print a warning (at configure
> time), if prefix is something other than /usr, /usr/local, or
> ~/.local?

I'm not sure the means to the goal, but the goal has be easy paths to
the destinations, to typical packager intermediate locations, with the
numerous special cases (debian!).

So, we need a a document in git, that enumerates all these conflicting
goals, and the paths to each goal.  So that we communicate to our
downstreams how to get what they want out of what we give them.

Not gonna be tonight, but gotta be before we ship next point release, it
is directly in the way of our path to being easy for all our intended
audiences.

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/20171207/4726263e/attachment.bin>