Bite of the Buildbugs!

Wed Dec 13 01:12:50 UTC 2017

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

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.

Thanks,

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane

On Tue, Dec 12, 2017 at 9:45 AM, Gary E. Miller via devel <devel at ntpsec.org>
wrote:

> 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
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20171213/e6c9a02b/attachment.html>