Originally reported in bug 203750: ------- Comment #8 From Brent Baude 2008-01-10 03:31:15 0000 [reply] ------- I hit a circular dep with FEATURES="test" on my packages. Check this out: baudequad ~ # FEATURES="test" emerge -pv `cat java.pkgs ` These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] www-servers/tomcat-6.0.14-r1 USE="test -doc -examples -source" [ebuild N ] dev-java/commons-dbcp-1.2.2 USE="test -doc -source" !!! Error: circular dependencies: ('ebuild', '/', 'dev-java/commons-dbcp-1.2.2', 'merge') depends on ('ebuild', '/', 'www-servers/tomcat-6.0.14-r1', 'merge') (hard) ('ebuild', '/', 'www-servers/tomcat-6.0.14-r1', 'merge') depends on ('ebuild', '/', 'dev-java/commons-dbcp-1.2.2', 'merge') (hard) !!! Note that circular dependencies can often be avoided by temporarily !!! disabling USE flags that trigger optional dependencies. baudequad ~ # This is for ppc64. Can the java herd peek at this? -- Looked at it briefly, the tests in commons-dbcp really at some point want org.apache.naming (which is in tomcat's catalina.jar) instead of javax.naming, which looks suspicious and I'm not sure it's really needed.
I question it as well, and I use commons-dbcp in Tomcat :) So does tomcat, they renamed that sucker to tomcat-dbcp.jar/naming-factory-dbcp.jar. Been a problem for me for a while in bug 205245. Looking at upstream home page, it says "Applications can use the commons-dbcp component directly or through the existing interface of their container / supporting framework." So I guess the tests are testing the container interface or etc? I figured it could be used directly and not require a container. Guess absolute worse case I could see about packaging catalina.jar on it's own. But would hope to avoid that.
Hi all, I had a problem which seems to be related with this topic. I keep tomcat-6.x masked since we (the company I work for) are forced to stick on tomcat-5.5.x; plus, I have test feature enabled in Portage, which altogether makes commons-dbcp won't have all its dependencies satisfied (test flag -> tomcat:6). My workaround has been disabling test on commons-dbcp, but I wonder if there's any way to make commons-dbcp tests work with tomcat-5.5 or to make Portage workarounds this issue by itself.
In fact, I think a new bug should be reported, since test FEATURE can be disabled for a particular call of emerge, but not permanently for a particular package (there's no package.feature). I'll open a bug and associate it with this one.
Hm, common sense tells me that the test that needs tomcat6 is testing only functionality when commons-dbcp is used in tomcat6, which is not always the case. So, it could simply drop the dependency, use has_version check and if tomcat6 is not there, patch the test out and spit an ewarn.
commons-dbcp-1.4-r2, for which a stable request was filed, no longer depends on tomcat for it's tests. Closing here.