From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922 Description of problem: ccm-tools has a dependency on ccm-config-libs, which means it will install without warnings on a machine with ccm-config-libs-1.1.x installed. However it will not work. Upgrading to ccm-config-libs-1.2.x will fix the problems, so the dependency should either be on ccm-config-libs >= 1.2 or on individual files in ccm-config-libs. Version-Release number of selected component (if applicable): ccm-tools-0.9.0-2 (from tip of dev @39491) Additional info:
Actually, ccm-tools does not have any dependency on ccm-config-libs. This is correct because ccm-tools itself does not require anything in ccm-config-libs. The package that should depend on ccm-config-libs is ccm-core. As of @39642, the buildRequires elements of application.xml are used to generate BuildRequires tags in the RPM. This means that the latest ccm-core source RPMs require junit, httpunit, junitperf, and servlet. However, we still have the problem that ccm-core binary RPMs should also depend on servlet. Here are some solutions to this that I can think of offhand: 1) add another type of dependency tag to application.xml that will cause a dependency to be generated in the RPM, but won't be treated as a ccm application. Example: <ccm:runRequires name="servlet" version="2.3"/> 2) add "Requires: servlet = 2.3" to rpm.spec.in. However, this isn't very forward-compatible. 3) create a one-off rpm spec file for core. This could be a lot of maintainence work. 4) have ccm-tools RPM depend on servlet 2.3. Same downside as #2 So, my preference would be #1. Thoughts?
Yeah, I think #1 is best.
@ 39788