Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=591298 --- Comment #8 from Mat Booth <fedora@xxxxxxxxxxxxxx> 2010-05-13 16:26:32 EDT --- (In reply to comment #7) > Noted that this is re-review > Noted that you've noted that this is a re-review. ;-) > Other problems: > - required for renames: check for proper Provides/Obsoletes was OK > - these are quite old: > > Provides: %{short_name} = %{version}-%{release} > > Obsoletes: %{short_name} < %{version}-%{release} > > And should be fairly safe to remove them for rawhide F14+ (currently on F-12 > only plexus-xmlrpc does and it will have to be revised anyway) > Agreed, this provides/obsoletes is ancient. Consider it gone. > > What is the reason to have: > > # enable OSGi automatic dep solving > > %define _use_internal_dependency_generator 0 > > %define __find_provides /usr/lib/rpm/osgideps.pl -p > > %define __find_requires /usr/lib/rpm/osgideps.pl -r > I believe they are not used/needed anywhere in the spec file. If they really > are needed, define them with %global. Isn't maven supposed to take care of > this? > This is to boot-strap automatic dep-solving for RPMs that provide OSGi bundles needed for Eclipse. Maven only generates the headers, it doesn't care about RPM dependencies. It is not yet enabled by default, hence these lines. They will be removed when it is ready. See bug #488352. I have changed them to use global. > - javadoc sub-package must have jpackage-utils in Requires (it is > owner of javadoc directory Done. > - jpackage-utils should be required in post/postun for %update_maven_depmap Done. > - provide backward compatible pom file with old GROUP_ID/ARTIFACT_ID. > jakarta-commons-codec > used %add_to_maven_depmap %{short_name} %{short_name} %{version} JPP > %{short_name} > If no package in Fedora needs the legacy pom, is this still necessary? If "org.apache.commons" if the right way, I'd rather just do that. > Suggestions (Not required for + :-) ): > - since you are already using install for copying files, why not use > it for creating dirs too? Instead of: > > mkdir -p %{buildroot}%{_javadocdir}/%{name}-%{version} > use > install -d -m 755 %{buildroot}%{_javadocdir}/%{name}-%{version} > > - another one: > > (cd %{buildroot}%{_javadocdir} && ln -sf %{name}-%{version} %{name}) > > Why create subshell when simple > ln -s %{name}-%{version} %{buildroot}%{_javadocdir}/%{name} > would be enough? > Good ideas, done. > - You also have more commons packages so I suggest you use %global to > define base_name as codec, short_name as commons-%{base_name} and use > base name in URL/Source0, elsewhere as needed. You will then be able to re-use > spec file changes more easily in the future. I don't normally have a problem search and replacing, but ok. :-) New SPEC/SRPM: http://mbooth.fedorapeople.org/reviews/apache-commons-codec.spec http://mbooth.fedorapeople.org/reviews/apache-commons-codec-1.4-7.fc13.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review