Bug 814931 - RPM mvn(...) provides in wrong package
Summary: RPM mvn(...) provides in wrong package
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: jpackage-utils
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stanislav Ochotnicky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-21 11:20 UTC by Mattias Ellert
Modified: 2012-05-08 08:58 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-08 08:58:37 UTC
Type: Bug


Attachments (Terms of Use)

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.


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