Bug 814931

Summary: RPM mvn(...) provides in wrong package
Product: [Fedora] Fedora Reporter: Mattias Ellert <mattias.ellert>
Component: jpackage-utilsAssignee: Stanislav Ochotnicky <sochotni>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: akurtako, dbhole, sochotni
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-08 08:58:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mattias Ellert 2012-04-21 11:20:12 UTC 
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)
Comment 1 Deepak Bhole 2012-05-03 14:15:45 UTC 
Adding sochotni to cc
Comment 2 Stanislav Ochotnicky 2012-05-04 09:22:54 UTC 
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.
Comment 3 Mattias Ellert 2012-05-05 02:51:48 UTC 
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.
Comment 4 Stanislav Ochotnicky 2012-05-07 07:47:43 UTC 
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.