> 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@ntpsec.org> wrote: > Yo Ian! > > On Sun, 10 Dec 2017 16:26:01 -0600 > Ian Bruene via devel <devel@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 > g...@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@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
