Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 589168 - Review Request: apache-commons-logging - rename of jakarta-commons-logging
Summary: Review Request: apache-commons-logging - rename of jakarta-commons-logging
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Alexander Kurtakov
QA Contact: Fedora Extras Quality Assurance
: 225933 (view as bug list)
Depends On:
Blocks: JakartaCommonsRename 589617
TreeView+ depends on / blocked
Reported: 2010-05-05 14:58 UTC by Stanislav Ochotnicky
Modified: 2010-05-07 09:56 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-05-07 07:25:25 UTC
akurtako: fedora-review+
kevin: fedora-cvs+

Attachments (Terms of Use)
changes against original 1.0.4-9.10 spec file (deleted)
2010-05-05 15:00 UTC, Stanislav Ochotnicky
no flags Details | Diff

Description Stanislav Ochotnicky 2010-05-05 14:58:18 UTC
Spec URL:

Package was renamed and version-bumped from 1.0.4. The build system was changed to use maven instead of ant.

apache-commons-logging is new name for jakarta-commons-logging - a simple, component oriented interface (org.apache.commons.logging.Log) together with wrappers for logging systems.

Comment 1 Stanislav Ochotnicky 2010-05-05 15:00:19 UTC
Created attachment 411642 [details]
changes against original 1.0.4-9.10 spec file

Just to see the changes made more easily

Comment 2 Alexander Kurtakov 2010-05-05 15:14:49 UTC
I'm taking this one.

Comment 3 Alexander Kurtakov 2010-05-05 19:22:42 UTC
*** Bug 225933 has been marked as a duplicate of this bug. ***

Comment 4 Alexander Kurtakov 2010-05-06 11:44:53 UTC
Unversioned javadoc directory should be created as a symlink in %install and there should be no %post/%postun for javadoc subpackage.

Comment 5 Stanislav Ochotnicky 2010-05-06 12:24:42 UTC

Spec URL:

Few other QA improvement changes noted in changelog as well

Comment 6 Alexander Kurtakov 2010-05-06 13:11:27 UTC

OK: rpmlint must be run on every package. Output:

apache-commons-logging.noarch: W: spelling-error %description -l en_US runtime -> run time, run-time, untimely
apache-commons-logging.noarch: W: self-obsoletion jakarta-commons-logging <= 0:1.0.4 obsoletes jakarta-commons-logging = 0:1.0.4
apache-commons-logging.noarch: W: non-conffile-in-etc /etc/maven/fragments/apache-commons-logging

False positives. 

OK: The package must be named according to the Package Naming Guidelines .
OK: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption. 
OK: The package must meet the Packaging Guidelines .
OK: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines .
OK: The License field in the package spec file must match the actual license.
OK: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.
OK: The spec file must be written in American English. 
OK: The spec file for the package MUST be legible. 
OK: The sources used to build the package must match the upstream source, as provided in the spec URL. 
OK: The package MUST successfully compile and build into binary rpms on at least one primary architecture. 
OK: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense.
OK: Packages must NOT bundle copies of system libraries.
OK: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. 
OK: A Fedora package must not list a file more than once in the spec file's %files listings. 
NOTOK: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. 

I don't see a reason why not using default %defattr(-,root,root,-)
From the guidelines:
Unless you have a very good reason to deviate from that, you should use %defattr(-,root,root,-) for all %files sections in your package. 

OK: Each package must consistently use macros. 
OK: The package must contain code, or permissable content. 
OK: Large documentation files must go in a -doc subpackage. 
OK: If a package includes something as %doc, it must not affect the runtime of the application. 
OK: Packages must not own files or directories already owned by other packages. 
OK: All filenames in rpm packages must be valid UTF-8. 

Please drop Package from the Summary.
Also javadoc subpackage will be better tohave a description like "API documentation for %{name}."
Please also use the default the permissions. I know that they will match in this case but we should use the defaults.

Comment 8 Alexander Kurtakov 2010-05-06 13:51:12 UTC

This package is APPROVED.

Comment 9 Stanislav Ochotnicky 2010-05-06 14:23:31 UTC
Thanks. Requesting CVS:

New Package CVS Request
Package Name: apache-commons-logging
Short Description: Apache Commons Logging
Owners: sochotni mbooth

Comment 10 Kevin Fenzi 2010-05-06 15:49:39 UTC
CVS done (by

Comment 11 Mat Booth 2010-05-06 19:06:52 UTC

Why is it necessary to specify:


That is unnecessary for commons-codec, for example:

Comment 12 Alexander Kurtakov 2010-05-06 20:48:50 UTC
(In reply to comment #11)
> Hi,
> Why is it necessary to specify:
> -Dmaven2.jpp.depmap.file="%{SOURCE1}"
> That is unnecessary for commons-codec, for example:

It's needed for the avalon-* jars. And I didn't insisted on adding poms to dead packages. Time can be better spend freeing logging from avalon.

Comment 13 Stanislav Ochotnicky 2010-05-07 07:25:25 UTC
Package built, closing. Thanks Alexander & Kevin

Comment 14 Sandro Mathys 2010-05-07 08:17:24 UTC
I see here at least two indications that the package renaming process was not done correctly:

Particularly of importance is this:

First, the reviewer never explicitly stated that he's aware of this being a renaming (and obviously wasn't) and second the Provides doesn't use macros.

Also, this is _no_ false positive but a real problem:
apache-commons-logging.noarch: W: self-obsoletion jakarta-commons-logging <=
0:1.0.4 obsoletes jakarta-commons-logging = 0:1.0.4

Now that the reviewer wasn't aware it's been a renaming doesn't matter as I filled that gap (and am well aware of it). But please correct the other two problems before you push this pkg to any repo.

Comment 15 Stanislav Ochotnicky 2010-05-07 09:40:42 UTC
I would say that summary with "rename of <oldpkg>" obviously pointed that this is re-review of existing package. Will keep in mind to be more explicit about it next time.

I fixed problem with self-deprecation in r4. My original idea was that new packages that would want to do "Requires: jakarta-commons-logging >= 1.1.1" would fail (because we only provide version up until 1.0.4 - last version of old name). So new specfiles would have to be fixed in order to work. But since we also needed to replace current jakarta-commons-logging-1.0.4, there was that Obsoletes...

>correct the other two problems

I counted only one other problem (thank you for it pointing out btw), if there is anything else I missed let me know.


Comment 16 Sandro Mathys 2010-05-07 09:56:35 UTC
(In reply to comment #15)
> I would say that summary with "rename of <oldpkg>" obviously pointed that this
> is re-review of existing package.

For me it's all clear and not your fault. You also stated that it's a renaming in the bug's description. But the reviewer MUST state that he's aware of the fact and that he checked for the special requirements (Provides/Obsoletes) - he didn't do either.

> I counted only one other problem (thank you for it pointing out btw), if there
> is anything else I missed let me know.

The two problems:
1) Provides didn't use marcos
2) self-obsoletion

...where in your specific case fixing 1) fixes 2)

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