Re: ✘Python 2.7 broken

[James Browning]

On Sun, Dec 13, 2020 at 6:06 AM ASSI via devel <devel at ntpsec.org> wrote:

> Hal Murray via devel writes:
> > I think you want to use DESTDIR if you are testing things after
> installing
> > them.
>
> No, never.  DESTDIR is purely for packaging so that the "install" you do
> has the correct directory structure, but doesn't mess up your actual
> system.  There is only the to-be-installed stuff in DESTDIR, so a "pure"
> test there cannot work anyway.
>
> > There is a layer of testing that we can't do in a normal environment.
> The
> > problem is that the previously installed libraries provide backup that
> we
> > don't want.  This is a variant on the problem of using the wrong
> libraries
> > when testing pre-install.
>
> That's an entirely different problem.  You may indeed want to test an
> actual install eventually, but DESTDIR doesn't give you that.
>

I was working on that but now it seems I should drop it.


> > We could fix that by adding a version check when loading libraries.
> That
> > version would have to include the time stamp rather than just a version
> number.
>
> Nope.  Please, let go of that timestamp nonsense you're so fond of, the
> only thing you achieve is making life difficult for folks who care about
> reproducible builds.
>

--build-epoch but at least it only complains if the build stamp does not
match. I think I was at least partly responsible for previous overzealous
behavior.


> > Gary said:
> >> Right.  Which is why DESTDIR is wrong.  You want to be using the built
> files
> >> before installing in DESTDIR.
> >
> > You want to test before install.  It would also be good to test post
> install,
> > but that gets complicated if you have installed into DESTDIR rather than
> the
> > normal working place.
>
> Again, DESTDIR is not meant to be that place and it won't work if you try.


 So, I should just plan to mostly revert a4c2c7 "bin test: from install
directory recording skips" minus the clean-up.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20201213/641ec38d/attachment.htm>