perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Bill Owens writes:
>
>This morning's round of updates is failing because it appears that a 
>dependency is asking for an install of
>python-jinja2 2.7.2-2.el7, which is a downgrade from the already installed 
>2-2.8-1.el7. I'm not sure which
>pS package is causing the issue, nor why a downgrade is needed; is there a 
>way to check where the
>dependency comes from?

The software behind the REST API was written using the Flask framework, which 
depends on Jinja2 and another package called Werkzeug.  I’d packaged up 
versions of all three as part of our own distribution, but it turns out that 
Red Hat had done the same thing with a slight difference:  the first letter 
in the package names were lowercase (python-jinja2 vs. python-Jinja2).  The 
uppercase versions met Red Hat’s naming guidelines, so I have no idea why 
they went lowercase, but they did.

To make a long story short, Matt Woodward had installed SaltStack on one of 
his systems, and there ended up being a conflict between jinja2 and Jinja2.  
(See messages in this thread from October 31 and November 14.)  Because of a 
quirk in the way YUM behaves, we had to do a set of the three uppercase-named 
packages with no files in them to make for a hands-off transition during an 
upgrade.  It went off without a hitch in the test bed, so it was released 
into the staging build.

Nothing in pS depends on anything other than python-flask, which depends on 
the other two packages.  If you can supply the exact error messages and let 
me know if your system has anything other than the toolkit installed, I’ll 
see what I can do to figure the situation out.  None of this will be in the 
4.0 release, so new installations and upgrades from 3.5.x won’t have this 
problem.

See also https://github.com/perfsonar/pscheduler/issues/215 

--Mark