✘Python 2.7 broken

[ASSI]

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.

> 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.

> We could also try uninstalling the old stuff, but then we would have to debug 
> and maintain that.

That's the exact moment when distro packagers will nope out, drop ntpsec
and never look at it again.

> 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.

> I think the gitlab tests run in an environment without anything pre-installed. 
>  Does that do any post-install testing?

The only way to do post-install testing is to set up a clean system,
then install the just built package and test there.  Some CI let you do
that and some distros do their package testing this way (openSUSE with
openQA, for instance).  Exactly what and how to test beyond "it
installed, the system is still up and you can run an executable without
it dumping core" is a difficult problem that's not really been solved
yet.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds