Bug 844769

Package Review
==============

Key:
- = N/A
x = Pass
! = Fail
? = Not evaluated

==== Generic ====
[x]: EXTRA Rpmlint is run on all installed packages.
[x]: EXTRA Spec file according to URL is the same as in SRPM.
[x]: MUST Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: MUST Package successfully compiles and builds into binary rpms on at
     least one supported primary architecture.
[x]: MUST %build honors applicable compiler flags or justifies otherwise.
[x]: MUST All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: MUST Buildroot is not present
[x]: MUST Package contains no bundled libraries.
[]: MUST Changelog in prescribed format.
[x]: MUST Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: MUST Sources contain only permissible code or content.
[-]: MUST Each %files section contains %defattr if rpm < 4.4
[x]: MUST Macros in Summary, %description expandable at SRPM build time.
[-]: MUST Package contains desktop file if it is a GUI application.
[-]: MUST Development files must be in a -devel package
[x]: MUST Package requires other packages for directories it uses.
[x]: MUST Package uses nothing in %doc for runtime.
[x]: MUST Package is not known to require ExcludeArch.
[x]: MUST Permissions on files are set properly.
[x]: MUST Package does not contain duplicates in %files.
[x]: MUST Package complies to the Packaging Guidelines
[x]: MUST Spec file lacks Packager, Vendor, PreReq tags.
[x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[-]: MUST Large documentation files are in a -doc subpackage, if required.
[x]: MUST 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 is included in %doc.
[!]: MUST License field in the package spec file matches the actual license. [1]
[x]: MUST Package consistently uses macro is (instead of hard-coded directory
     names).
[x]: MUST Package is named using only allowed ascii characters.
[x]: MUST Package is named according to the Package Naming Guidelines.
[x]: MUST Package does not generate any conflict.
[x]: MUST Package obeys FHS, except libexecdir and /usr/target.
[x]: MUST Package must own all directories that it creates.
[x]: MUST Package does not own files or directories owned by other packages.
[x]: MUST Package installs properly.
[x]: MUST Package is not relocatable.
[x]: MUST Requires correct, justified where necessary.
[x]: MUST Rpmlint is run on all rpms the build produces.
[x]: MUST Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: MUST Spec file is legible and written in American English.
[x]: MUST Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[-]: MUST Package contains systemd file(s) if in need.
[x]: MUST File names are valid UTF-8.
[x]: SHOULD Reviewer should test that the package builds in mock.
[x]: SHOULD If the source package does not include license text(s) as a
     separate file from upstream, the packager SHOULD query upstream to
     include it. [2]
[x]: SHOULD Dist tag is present.
[x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin,
     /usr/sbin.
[!]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q
     --requires). [3]
[?]: SHOULD Package functions as described.
[x]: SHOULD Latest version is packaged.
[x]: SHOULD Package does not include license text files separate from
     upstream.
[x]: SHOULD SourceX / PatchY prefixed with %{name}.
[x]: SHOULD SourceX is a working URL.
[-]: SHOULD Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: SHOULD Package should compile and build into binary rpms on all supported
     architectures.
[-]: SHOULD %check is present and all tests pass.
[x]: SHOULD Packages should try to preserve timestamps of original installed
     files.
[!]: SHOULD Spec use %global instead of %define. [4]


==== Java ====
[x]: MUST If source tarball includes bundled jar/class files these need to be
     removed prior to building
[x]: MUST Packages have proper BuildRequires/Requires on jpackage-utils
[x]: MUST Fully versioned dependency in subpackages, if present.
[-]: MUST Javadoc documentation files are generated and included in -javadoc
     subpackage
[-]: MUST Javadoc subpackages have Requires: jpackage-utils
[-]: MUST Javadocs are placed in %{_javadocdir}/%{name} (no -%{version}
     symlink)
[x]: SHOULD Package has BuildArch: noarch (if possible)
[x]: SHOULD Package uses upstream build method (ant/maven/etc.) 


Notes / Issues:
[1] The pom.xml file says the license is LGPL, not ASL.

[2] I would ask that you file an issue for upstream to include a license file, but given that this is already a deprecated project, I don't know how much luck you'll have with that.

[3] I think that jbosscache-support and jbosscache-support-xslt should each require jbosscache-support-parent, so that things which buildrequire either of those will work.  and jbosscache-support-parent should not require jbosscache-support, as far as I can tell.  (If I've misunderstood, please clarify the current deps)

[4] Please use global rather than define in line 1 of the spec.

Also, please note why tests are being skipped (lack of testng, etc.)

Thanks.

> [3] I think that jbosscache-support and jbosscache-support-xslt should each
> require jbosscache-support-parent, so that things which buildrequire either
> of those will work.  and jbosscache-support-parent should not require
> jbosscache-support, as far as I can tell.  (If I've misunderstood, please
> clarify the current deps)

From looking at the pom files, it appears that:

1. jbosscache-support is parent of jbosscache-support-xslt
2. jbosscache-support is parent of jbosscache-support-parent
3. jbosscache-support depends on nothing

AFAICT, the jbosscache-core package's pom file requires only jbosscache-support-parent, which will in turn pull in jbosscache-support as a dependency. I don't think there is a case where the jbosscache-support package will be a direct BR.

Of course, we could do what you mention instead and it would still work. I would just need to update the jbosscache-core package to BR jbosscache-support instead of jbosscache-support-parent.

I chose the package requires to reflect what is happening in the pom files. If this is counterintuitive I can change it.

It was actually the package naming that was confusing.  I got mixed up about which pom was in which package; one would think that the one called "parent" would be the "parent" of the other two.  So your deps are correct.  Now that I've got that straight, though, my question is about the name choice.  The subdirectory in which the pom lives is called "common", and the artifactid in the pom is "jbosscache-common-parent".  It would make more sense to me to make the subpackage name match the artifactId.  You can do this with:

%package -n jbosscache-common-parent

The -n prevents the subpackage from being prefixed with the main package name.

Feel free to get a second opinion on this from other Java SIG folks, though.

Spec URL: http://madsa.fedorapeople.org/jbosscache-support.spec
SRPM URL: http://madsa.fedorapeople.org/jbosscache-support-1.6-2.fc17.src.rpm

Looks good.

APPROVED

New Package SCM Request
=======================
Package Name: jbosscache-support
Short Description: JBossCache support package
Owners: madsa arg
Branches: f17
InitialCC:

Git done (by process-git-requests).

jbosscache-support-1.6-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/jbosscache-support-1.6-2.fc17

jbosscache-support-1.6-2.fc17 has been pushed to the Fedora 17 testing repository.

jbosscache-support-1.6-2.fc17 has been pushed to the Fedora 17 stable repository.