[Bug 446134] Review Request: jsr-305 - reference implementation of JSR-305

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: jsr-305 - reference implementation of JSR-305


https://bugzilla.redhat.com/show_bug.cgi?id=446134


tibbs at math.uh.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tibbs at math.uh.edu




------- Additional Comments From tibbs at math.uh.edu  2008-06-28 18:37 EST -------
I have essentially no idea what this package is for, and very little knowledge
of Java, but it's been in the queue for six weeks and I can read the packaging
guidelines as well as anyone else so I'll see what I can do.

This builds fine for me; rpmlint says:
  jsr-305.x86_64: W: non-conffile-in-etc /etc/maven/fragments/jsr-305
Unfortunate; these should be under /usr/share but that's what our maven package
does so you have no choice.
 
  jsr-305.x86_64: W: non-standard-group Development/Libraries/Java
  jsr-305-javadoc.x86_64: W: non-standard-group Development/Documentation
These don't matter; we don't care what goes in Group:.

The URL in the spec (and the comment before the License: tag, and what's in
Source1) are 404 for me.  It works if you remove the "index.html" bit.

I don't think it's necessary to include a copy of the upstream web page to prove
the license, although if you have a copy of the email sent in response to your
query, perhaps you might want to include that.  If you do want to include a
copy, though, please do use a functioning URL.

You will need to include instructions for actually obtaining the subversion
snapshot that you include in the package.  And it would be a good idea to
version the tarball as well.  See http://fedoraproject.org/wiki/Packaging/SourceURL

Looking at the debug package, it seems that a bunch of the source is missing.  I
do not know enough about java to tell if something's gone wrong here or if the
source files just aren't supposed to be there for whatever reason.  Can you have
a look?

I thought the Java folks had decided that they didn't want to make unversioned
symlinks for javadocs.  I don't, however, see it in any of the guidelines,
neither encouraged nor discouraged.

This package should not own /etc/maven/fragments.  The same goes for
/usr/share/maven2/poms.  Unfortunately this is actually specified by the
guidelines, so I'm working to try and get the guidelines fixed, because this is
simply broken.

The guidelines indicate that all of the aot compilation bits should be
conditionalized.

X can't compare source files with upstream; no instructions for making the svn 
   checkout and Source1: URL does not exist.
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text not included upstream.
* BuildRequires are proper.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
? debuginfo package looks a bit too empty.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
  jsr-305-0-0.1.20080527svn.fc10.x86_64.rpm
   jsr-305-0.jar.so()(64bit)
   jsr-305 = 0-0.1.20080527svn.fc10
  =
   /bin/sh
   java >= 1.5
   java-gcj-compat >= 1.0.31
   jpackage-utils
   libgcc_s.so.1()(64bit)
   libgcc_s.so.1(GCC_3.0)(64bit)
   libgcj_bc.so.1()(64bit)
   libz.so.1()(64bit)

  jsr-305-javadoc-0-0.1.20080527svn.fc10.x86_64.rpm
   jsr-305-javadoc = 0-0.1.20080527svn.fc10
  =
   jpackage-utils
   jsr-305 = 0-0.1.20080527svn.fc10

* %check is not present; no test suite usptream.  (Although there's a couple of 
   test directories in the tarball, they're empty.)
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
X shouldn't own /etc/maven/fragments or /usr/share/maven2/poms
* no duplicates in %files.
* file permissions are appropriate.
X scriptlets shoudl consitionalize the aot bits.
* code, not content.
* %docs are not necessary for the proper functioning of the package.
* no pre-built jars
* single jar, named after the package
* jarfiles are under _javadir.
* javadocs are under _javadocdir.
* maven called properly.
* no wrapper script necessary.
X gcj should be called conditionally.

-- 
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, or are watching someone who is.