Bite of the Buildbugs!

[Gary E. Miller]

Yo Ian!

On Sun, 10 Dec 2017 16:26:01 -0600
Ian Bruene via devel <devel at ntpsec.org> wrote:

> On 12/10/2017 10:52 AM, Eric S. Raymond wrote:
> > Ugly, but simple.  I'd like to hear counterargument from Gary and
> > Fred before we make a final decision. Keep it succint, guys.  
> 
> Agreed. My main concern is that trying to be clever here has many
> ways to go wrong, and few ways to detect them before it gets to users.

Sorry to be late responding, been recovering from a lung crud going around
my area locally...

> > Do you understand the problem well enough that you could specify an
> > upstream fix?  
> 
> I'm not yet certain whether python or the distributions have 
> jurisdiction here. Earlier comments from rlaager suggest that it is
> the distributions. Working on getting an error specification...

Unless, and until, we get ntpsec has a pip package, the python dwnstream
rules do not apply.  Since the core of ntpsec is, currently, C, putting
ntpsec in pip would be a mistake, probably not even possible.

As for the distributions, nothing ntpsec can do has any force on
downstream.  Sure, we can make things easier, or harder, for them, but
they are free to, and do, patch however they feel like.

IMHO, our packaging responsibilities, and priorities, would be in
roughtly in order from most to least important.

1.  Maintain a master git head that is easy for anyone to install
directly from our git or tarball.

2. Provide tools, options and support, for binary downstreams (Debian,
Mint, etc.), to repackage ntpsec components as binaries, integrated with
their install tools.

3. Provide tools, options and support for source downstreams (Gentoo, etc.)
to create install scripts.

Clearly we control #1.  Clearly binary distros retain control over #2.
Similarly source distros over #3.

For #2 and #3, all we can do is be helpful and responsive to heir
wishes

Each of these three targets needs to be respectful of the other.  Being
respectful means each installs into the users systems in their own
reserved spots, separate from the other's reserved spots.

One way we help that is to offer a rich variety of install options that
aallow binary and srouce distributions to use our software to install

The differenecs are small, but important, and kinda laid out in the FHS.

Installs from git go into /usr/local/XXXX.  That keeps us from stepping on
the distro version of netsec.

Binary distro installs, unexpectedly to some, go into a temporary
location (/var/tmp/XX?).  Then it is up to the binary packager to
put the binaries, man pages, config files, etc., into a distro
standard package (.deb, .run, .zip, etc.).  Then, later, up to the package
installer to put the binaries in the proper place on the user's disk.
Usually /usr/{bin,sbin,lib, etc.}.

Source distro installs will be similar to git installs, except they'll
apply some patches, build the binaries, and install in the /usr tree
similar to a binary distro.

It is right and proper for binary and source distros to, by default,
install ntpsec in primary positions, and do what is necessary to make
ntpsec ready to run.  With minimal, or no, further configuration.

IMHO, it is not right, for a git install to do so.  For many reasons.
We do not want to step on distro installed packages.  The user maybe
just building the binaries for private testing, or installing on a
system not the current one.  Since we can not read their minds, we
give them lots of tools (--prefix, --exec-prefix, etc.) to easily do
what they want/need to do.

Not just my opinion, but a fundamental part of the philosophy of the FHS.

For new, we can stick to our part, direct git installs, and otherwise
wait for distro input on what the want from us.

Which, finally, brings us to what we need to do to help ourselves
and our git users, to install and use our package.

Our part then splits into 2 nice tasks.  First, we give the user the
tools (waf, sctips, etc.) to install in our proper place (/usr/local/, or
as overrdden with --prefix, etc.).

The second, is where I feel we have been not so good, and much of recent
activity has been dancing around.  Part of the git install process s/b
to analyze the current system, look at PYTHONPATH, sys.path, .pth files,
and recommend to the user the easist way to configure his system to
use his new files.  

We must not make changes by default, so as not to disrupt Gentoo style
source installs, or Debian style binary package building.  And the
binary and ebuild type hosts will already likely be configure to do
their right thing.

That said, I'd be happy to have a non-default option to perform some
actions on the current system to configure it to use the new stuff
just installed in /usr/local/

I have been happy to red discussions here of sys.path and .pth.  All
new to me.  I'm seeing cool new options, and potential serious problems.

Having been sick, I missed a lot of the PYTHONPATH, sys.path and .pth
discussion.  Can someone(s) post quick compare and contrast of these
three ways to proceed?

RGDS
eARY
---------------------------------------------------------------------------
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/20171211/30d915e6/attachment.bin>