EPEL tomcat package CVEs

[Aaron Knister]

Thanks for the tomcat package-- it's a huge help :)

I did notice, though, that the verison in use (7.0.33) has some CVEs
associated with it (http://tomcat.apache.org/security-7.html). I've worked
on getting 7.0.54 to build but it has the following issues:

- needs ant 1.8 (I have an ant18 package I'm going to look at submitting to
EPEL)

I've written it similar to the ant17 package in that it can't co-exist with
the current version of ant but should be a drop-in replacement. Since it's
only a build-time dependency I think this will be OK.

- needs ecj  4.7

I find this a little perplexing.I've got patches that alleviate the
compile-time issues with tomcat 7 using the newer ecj but I don't know what
the long-term effects are. I had thought about creating an ecj4 package but
I'm not clear on how to namespace it so it could co-exist with the current
ecj package in EL6.

Any thoughts/guidance would be appreciated.

Best,
Aaron
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3.4 for 7

[Aaron Knister]

 On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
 
 
 On Apr 26, 2014 8:27 PM, Aaron Knister aaron.knis...@gmail.com wrote:
 
  We use both EPEL and SCL in my org. I didn't see this addressed in the 
  email chain but I'm concerned about what'll happen if/when SCL includes 
  python34. There are technical means to work around this but it 
  fundamentally makes EPEL and SCL incompatible. I don't believe SCL is 
  considered a layered product but maybe I'm wrong :)
 
 If red hat does the right thing and namespaces their scl packages then there 
 shouldn't be any conflicts.  Scls are intended to be isolated from system 
 packages while epel packages are intended to integrate into the system.
 
 -Toshio
 
The contents are namespaced but the package names are not. We'll end up with a 
package called python34 in each repo that are incompatible. The SCL package 
will have a prefix of /opt/rh/python34/root whereas the EPEL package will have 
a prefix of /. Undoubtedly there will be packages in EPEL (that aren't simply 
python34) modules that will require python34 that we'll be unable to use on 
systems with SCL because of the python34 package conflict. I wish RHEL had 
prefixed the package names with scl- but alas they did not. 

 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel