perfSONAR User Q&A and Other Discussion

[Laurie Zirkle <>]

FWIW, I have been seeing the same issue since earlier this week.  My
automatic updates were failing because of the conflict.  I have the
pS-PerfSONAR packages installed via yum on top of our own CentOS-7
installation.

# yum update

.....

Installing for dependencies:
 python-babel            noarch 0.9.6-8.el7             base              1.4 
M
 python-flask            noarch 1:0.10.1-3.el7          epel              204 
k
 python-jinja2           noarch 2.7.2-2.el7             base              515 
k
 python-werkzeug         noarch 0.9.1-1.el7             epel              562 
k

...

  file /usr/lib/python2.7/site-packages/jinja2/sandbox.pyc from
install of python-jinja2-2.7.2-2.el7.noarch conflicts with file from
package python-Jinja2-2.8-1.el7.centos.noarch



--
Laurie


On Mon, Nov 28, 2016 at 10:40 AM, Mark Feit 
<>
 wrote:
> 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
>
>