Red Hat Bugzilla – Bug 814931
RPM mvn(...) provides in wrong package
Last modified: 2012-05-08 04:58:37 EDT
Description of problem: The mnv(...) rpm provides end up in the main rpm package rather than in the rpm subpackage containing the jar. Version-Release number of selected component (if applicable): jpackage-utils-1.7.5-18.fc17 Additional info: This is best explained by an example. The springframework package in the release (springframework-3.1.1-2.fc17) was built using jpackage-utils-1.7.5-16.fc17 and has the mvn(...) rpm provides in the subpackages where the jar is: $ repoquery --provides springframework | grep ^mvn mvn(org.springframework:spring-core) mvn(org.springframework:spring-parent) $ repoquery --provides springframework-aop | grep ^mvn mvn(org.springframework:spring-aop) $ repoquery --provides springframework-beans | grep ^mvn mvn(org.springframework:spring-beans) and so on. However, rpmbuild --rebuild of the srpm with jpackage-utils-1.7.5-18.fc17 results in that all the mvn(...) provides are registered in the main package and not in the subpackages with the jars. $ rpm -q --provides -p rpmbuild/RPMS/noarch/springframework-3.1.1-2.fc17.noarch.rpm | grep ^mvn mvn(org.springframework:spring-aop) mvn(org.springframework:spring-beans) mvn(org.springframework:spring-context) mvn(org.springframework:spring-core) mvn(org.springframework:spring-expression) mvn(org.springframework:spring-instrument) mvn(org.springframework:spring-jdbc) mvn(org.springframework:spring-parent) mvn(org.springframework:spring-tx)
Adding sochotni to cc
I assume that this is caused by incorrect use of %add_maven_depmap macro. If you are placing jars and poms in a subpackage, the fragment file for those gids:aids should be there as well. In other words you should use "-f <subpackage>" for add_maven_depmap. This will create a fragment file called %{name}-<subpackage which you can include in that subpackage. It would help to see the spec though so I can be certain.
So the changed behaviour of the automatic provision generator is intentional and not a regression? Packages that previously were relying on the old behaviour to get the autogenerated provides in the subpackages need to be changed and use separate fragments files for each subpackage? It does make sense to use a separate fragments file for each subpackage, so I am not opposed to the change, as long at it was intentional.
Yes it was intentional. Originally we generated fragments from pom files. But they only contain the gid:aid as provided by upstream. Sometimes we want to provide additional mappings (-a argument to add_maven_depmap). For example javax.servlet mapping in tomcat or other implementation. This information got lost when mvn() was generated from poms so this was actually a fix. It was not correct originally.