Attn: Install path debaters

[Gary E. Miller]

Yo Richard!

On Thu, 4 Jan 2018 15:29:24 -0600
Richard Laager via devel <devel at ntpsec.org> wrote:

> On 01/04/2018 12:54 PM, Gary E. Miller via devel wrote:
> > functional tests are run on the code in many different locations.  
> 
> This concern is valid. Can you provide examples of what sort of tests
> are run?

Basic QA things.  Usually file names, file count, file sizes, and file
checksums.  Some devs will also add some simple regressions tests.

The gcc package is a special case, they use the built gcc to build
another identical gcc, and if the two do not match bit-for-bit, they
fail.

> For example, within the build tree is fine:
> ./waf check

Yup, but then Gentoo usually has the one extra sandbox, maybe two.

Similar things happen when a dev builds an apt package.

> Specifically, which commands are run for this:
> 
> > After the package
> > is built, several saanity checks are made to the results of the
> > build.  

Depends on the dev.  Some are lazy, some are not.  Also depends on the
tools upstream provides. gpsd has gpsfake and tons of regression tests.
NTPsec not so much.

> > Any paths embedded in the results may result in breakage.  A
> > trivial and very obvious way to manage any embedded paths is
> > required.  
> 
> It either breaks or it doesn't. Saying "may result in breakage"
> indicates you haven't actually tested this.

Oh, I've tested it many times, I'm a long time Gentoo user.  And I
do not need to look at !615 to know it will break Gentoo binary 
packages depending on how/where the user installs it.

> Please test the actual code in the relevant situation and show the
> results.

Don't need to.  As explained, it can not work in many Gentoo scenarios.
In addition to being FHS non-compliant, and violating decades of
UNIX precedent.

> I'd like to again reiterate that tons of packages embed prefix and
> similar paths in their build products.

Ah, but we are not just talking about embedding strings in build
products!  We are talking about installing .pth files out of
tree.

> $ strings /usr/lib/x86_64-linux-gnu/libpurple.so.0 | grep /usr
> /usr/share
> /usr/share/locale
> /usr/lib/purple-2/

Yes, and all FHS compliant too!

> Please explain how Pidgin works on Gentoo, but NTPsec can't.

Different case.  Pidgin is installed in /usr.  Here we are talking about
installs into /usr/local, ~, sandboxes, etc.

And, I do not see any .pth files in Pidgin.

> > Some Gentoo fans do things in an even more complicated way.  The
> > results of the above described build, instead of being installed in
> > the local system, are installed in yet another sandbox.  The
> > contents of that sandbox are then all rolled up into a tar file.
> > That tar file can then be copied to other hosts and installed into
> > any of the usual locations (/usr, /usr/local, ~/, etc.).  
> 
> Agreed. This is how binary distro packages work.

Yup, and no way to install out of tree .pth files that way.

Show stopper.  End of topic.

> > Once again, any paths embedded in the results may result in
> > breakage.  
> 
> It doesn't result in breakage, I promise. For evidence, see the fact
> that the Debian NTPsec package works right now.

I don't care about Debian.  I don't care about packages built by system
devs for system install.  Wrong topic.  Off topic.  That was never an
issue.  PYTHONPATH, and embedded paths are simply not needed for system
installs.  We are talking about installs into /usr/local, ~, sandboxes,
etc.

> > One can not merely embed the final paths in the files as the
> > final paths can not be known at build time  
> 
> The final paths *are* available at build time.

Uh, no.  As I said before, Gentoo binary packages can be installed
ANYWHERE in the tree.  You can build one binary package, and install the
same package in /usr, /usr/local, ~, sandboxes, or any other place I
want, on any other Gentoo host or Vm that I want.


> I know that I intend to
> install to /usr, so I set --prefix=/usr. This is not complicated, nor
> specific to NTPsec.

And, once again.  Off topic.  Wrong topis.  Never been an issue.

The case at hand is installing into /usr/local, ~, or other sandboxes.
NTP Classic, and NTPsec have worked in /usr for a very long time.  Stop
fixing something that is not broken.  Look at the broken part.

RGDS
GARY
---------------------------------------------------------------------------
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/20180104/d5f8edc1/attachment.bin>