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
pgpIOSFIN1yEl.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel