<div dir="ltr"><div><div><br>> 2. Provide tools, options and support, for binary downstreams (Debian,<br>> Mint, etc.), to repackage ntpsec components as binaries, integrated with<br>
> their install tools.<br><br></div>As a start, as Richard has already done the work of packaging ntpsec for Debian, perhaps we could include his "patches" in HEAD?  Then I can try them out regularly on Ubuntu and Debian variants I run, and file appropriate reports.<br><br></div>Thanks,<br>
</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">-- <br>Sanjeev Gupta<br>+65 98551208     <a href="http://www.linkedin.com/in/ghane" target="_blank">http://www.linkedin.com/in/ghane</a></div></div>
<br><div class="gmail_quote">On Tue, Dec 12, 2017 at 9:45 AM, Gary E. Miller via devel <span dir="ltr"><<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yo Ian!<br>
<span class=""><br>
On Sun, 10 Dec 2017 16:26:01 -0600<br>
Ian Bruene via devel <<a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a>> wrote:<br>
<br>
> On 12/10/2017 10:52 AM, Eric S. Raymond wrote:<br>
</span>> > Ugly, but simple.  I'd like to hear counterargument from Gary and<br>
> > Fred before we make a final decision. Keep it succint, guys.<br>
><br>
> Agreed. My main concern is that trying to be clever here has many<br>
> ways to go wrong, and few ways to detect them before it gets to users.<br>
<br>
Sorry to be late responding, been recovering from a lung crud going around<br>
my area locally...<br>
<span class=""><br>
> > Do you understand the problem well enough that you could specify an<br>
> > upstream fix?<br>
><br>
> I'm not yet certain whether python or the distributions have<br>
> jurisdiction here. Earlier comments from rlaager suggest that it is<br>
> the distributions. Working on getting an error specification...<br>
<br>
</span>Unless, and until, we get ntpsec has a pip package, the python dwnstream<br>
rules do not apply.  Since the core of ntpsec is, currently, C, putting<br>
ntpsec in pip would be a mistake, probably not even possible.<br>
<br>
As for the distributions, nothing ntpsec can do has any force on<br>
downstream.  Sure, we can make things easier, or harder, for them, but<br>
they are free to, and do, patch however they feel like.<br>
<br>
IMHO, our packaging responsibilities, and priorities, would be in<br>
roughtly in order from most to least important.<br>
<br>
1.  Maintain a master git head that is easy for anyone to install<br>
directly from our git or tarball.<br>
<br>
2. Provide tools, options and support, for binary downstreams (Debian,<br>
Mint, etc.), to repackage ntpsec components as binaries, integrated with<br>
their install tools.<br>
<br>
3. Provide tools, options and support for source downstreams (Gentoo, etc.)<br>
to create install scripts.<br>
<br>
Clearly we control #1.  Clearly binary distros retain control over #2.<br>
Similarly source distros over #3.<br>
<br>
For #2 and #3, all we can do is be helpful and responsive to heir<br>
wishes<br>
<br>
Each of these three targets needs to be respectful of the other.  Being<br>
respectful means each installs into the users systems in their own<br>
reserved spots, separate from the other's reserved spots.<br>
<br>
One way we help that is to offer a rich variety of install options that<br>
aallow binary and srouce distributions to use our software to install<br>
<br>
The differenecs are small, but important, and kinda laid out in the FHS.<br>
<br>
Installs from git go into /usr/local/XXXX.  That keeps us from stepping on<br>
the distro version of netsec.<br>
<br>
Binary distro installs, unexpectedly to some, go into a temporary<br>
location (/var/tmp/XX?).  Then it is up to the binary packager to<br>
put the binaries, man pages, config files, etc., into a distro<br>
standard package (.deb, .run, .zip, etc.).  Then, later, up to the package<br>
installer to put the binaries in the proper place on the user's disk.<br>
Usually /usr/{bin,sbin,lib, etc.}.<br>
<br>
Source distro installs will be similar to git installs, except they'll<br>
apply some patches, build the binaries, and install in the /usr tree<br>
similar to a binary distro.<br>
<br>
It is right and proper for binary and source distros to, by default,<br>
install ntpsec in primary positions, and do what is necessary to make<br>
ntpsec ready to run.  With minimal, or no, further configuration.<br>
<br>
IMHO, it is not right, for a git install to do so.  For many reasons.<br>
We do not want to step on distro installed packages.  The user maybe<br>
just building the binaries for private testing, or installing on a<br>
system not the current one.  Since we can not read their minds, we<br>
give them lots of tools (--prefix, --exec-prefix, etc.) to easily do<br>
what they want/need to do.<br>
<br>
Not just my opinion, but a fundamental part of the philosophy of the FHS.<br>
<br>
For new, we can stick to our part, direct git installs, and otherwise<br>
wait for distro input on what the want from us.<br>
<br>
Which, finally, brings us to what we need to do to help ourselves<br>
and our git users, to install and use our package.<br>
<br>
Our part then splits into 2 nice tasks.  First, we give the user the<br>
tools (waf, sctips, etc.) to install in our proper place (/usr/local/, or<br>
as overrdden with --prefix, etc.).<br>
<br>
The second, is where I feel we have been not so good, and much of recent<br>
activity has been dancing around.  Part of the git install process s/b<br>
to analyze the current system, look at PYTHONPATH, sys.path, .pth files,<br>
and recommend to the user the easist way to configure his system to<br>
use his new files.<br>
<br>
We must not make changes by default, so as not to disrupt Gentoo style<br>
source installs, or Debian style binary package building.  And the<br>
binary and ebuild type hosts will already likely be configure to do<br>
their right thing.<br>
<br>
That said, I'd be happy to have a non-default option to perform some<br>
actions on the current system to configure it to use the new stuff<br>
just installed in /usr/local/<br>
<br>
I have been happy to red discussions here of sys.path and .pth.  All<br>
new to me.  I'm seeing cool new options, and potential serious problems.<br>
<br>
Having been sick, I missed a lot of the PYTHONPATH, sys.path and .pth<br>
discussion.  Can someone(s) post quick compare and contrast of these<br>
three ways to proceed?<br>
<br>
RGDS<br>
eARY<br>
------------------------------<wbr>------------------------------<wbr>---------------<br>
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703<br>
        <a href="mailto:gem@rellim.com">gem@rellim.com</a>  Tel:<a href="tel:%2B1%20541%20382%208588" value="+15413828588">+1 541 382 8588</a><br>
<br>
            Veritas liberabit vos. -- Quid est veritas?<br>
    "If you can’t measure it, you can’t improve it." - Lord Kelvin<br>
<br>______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a><br>
<a href="http://lists.ntpsec.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ntpsec.org/<wbr>mailman/listinfo/devel</a><br></blockquote></div><br></div>