Bug 814931 - RPM mvn(...) provides in wrong package
RPM mvn(...) provides in wrong package
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: jpackage-utils (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stanislav Ochotnicky
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-21 07:20 EDT by Mattias Ellert
Modified: 2012-05-08 04:58 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-08 04:58:37 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mattias Ellert 2012-04-21 07:20:12 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)
Comment 1 Deepak Bhole 2012-05-03 10:15:45 EDT
Adding sochotni to cc
Comment 2 Stanislav Ochotnicky 2012-05-04 05:22:54 EDT
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-04 22:51:48 EDT
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 03:47:43 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.