Bug 462560

I do have a small question about how the release tag should be numbered.  On the upstream web site, they only have downloadable ZIP files for versions up to 1.1.3.4c.  However, in their CVS tree they have tags for 1_1_4 and 1_1_4b.  (I grabbed that last tag as I documented in the .spec file.)  Since, I grabbed the code out of CVS, should there be a "cvs" string in the release, or is that not necessary since I was grabbing a specific CVS tag?

Dunno about the version naming; your rationale sounds plausible to me but I could also see it going the other way.

A few rpmlint issues:

xmlpull-api.i386: W: non-standard-group Development/Java
(==> Development/Libraries ?)

xmlpull-api.i386: W: incoherent-version-in-changelog 1.1.4b-2 ['0:1.1.4b-2.fc9', '0:1.1.4b-2']
This goes away if you remove the "Epoch: 0" from the spec file. Is the epoch actually necessary? If so, the changelog entry should be 0:1.1.4b-2

xmlpull-api-javadoc.i386: W: non-standard-group Development/Documentation
(==> Documentation ?)

FYI, the first and third rpmlint issues above aren't something we care about.  As for the second, you should generally not use "Epoch: 0" in a Fedora package.  And to address the question in comment #1, the answer depends on whether upstream believes that version 1.1.4b actually exists.  Some upstreams do tag releases but don't worry about generating tarballs; other upstreams might make a tag but wouldn't want to get bug reports for a version they didn't release.  So you need to ask them.

Some other comments:

Please remove the commented cruft from the specfile.  (Well, you can't remove the horrible license block from the top, of course, but you can remove the other stuff that just clutters 

If you are going to use to use all of those macro forms (%{__cp} and such), you need to use them consistently.  Which means bare "ln" and "mv" should not be used.  The spec file looks much cleaner if you just don't use them, but that's up to you.

Why move the pre-build jars to "jar.no" instead of just deleting them?  You can delete them all with a single find command, so your %prep section could just be two lines.

Before this bug gets closed, I just want to say that I have seen these comments now, and I should have a new spec files out soon.

(In reply to comment #3)
> FYI, the first and third rpmlint issues above aren't something we care about. 
> As for the second, you should generally not use "Epoch: 0" in a Fedora package.

The Epoch: 0 has been removed.

>  And to address the question in comment #1, the answer depends on whether
> upstream believes that version 1.1.4b actually exists.  Some upstreams do tag
> releases but don't worry about generating tarballs; other upstreams might make
> a tag but wouldn't want to get bug reports for a version they didn't release. 
> So you need to ask them.
> 
> Some other comments:
> 
> Please remove the commented cruft from the specfile.  (Well, you can't remove
> the horrible license block from the top, of course, but you can remove the
> other stuff that just clutters 

Done.

> If you are going to use to use all of those macro forms (%{__cp} and such), you
> need to use them consistently.  Which means bare "ln" and "mv" should not be
> used.  The spec file looks much cleaner if you just don't use them, but that's
> up to you.

I converted everything to bare commands.

> Why move the pre-build jars to "jar.no" instead of just deleting them?  You can
> delete them all with a single find command, so your %prep section could just be
> two lines.  

Done.

I have posted a new spec file: http://www.guthrie.info/RPMS/f10/xmlpull-api.spec
I have also posted a new SRPM: http://www.guthrie.info/RPMS/f10/xmlpull-api-1.1.4b-3.fc10.src.rpm

These are still using the same source.  I need to verify that the source code is still up to date.  If it is not, then I will be posting a new SRPM with new source tomorrow.

By the way, here is the rpmlint output from the latest code:

xmlpull-api-javadoc.i386: W: non-standard-group Development/Documentation
xmlpull-api.i386: W: non-standard-group Development/Java
2 packages and 0 specfiles checked; 0 errors, 2 warnings.

Output from rpmlint:

xmlpull-api.x86_64: W: non-standard-group Development/Java
xmlpull-api-javadoc.x86_64: W: non-standard-group Development/Documentation
xmlpull-api.spec:39: W: non-standard-group Development/Java
xmlpull-api.spec:66: W: non-standard-group Development/Documentation
xmlpull-api.spec:140: W: libdir-macro-in-noarch-package (main package) %{_libdir}/gcj/%{name}
3 packages and 1 specfiles checked; 0 errors, 5 warnings.

All of which are fine.  We don't care about the group, and gcj forces you to use %{_libdir}.

MUST items:
OK: rpmlint output
OK: package named according to Package Naming Guidelines
OK: spec file name matches package name
OK: package meets packaging guidelines
OK: package license meets licensing guidelines
OK: license field matches actual license
OK: license file included in %doc [1]
OK: spec file in American English
OK: spec file is legible
OK: sources match upstream sources [2]
OK: package builds successfully on at least one primary arch (x86_64)
NA: appropriate use of ExcludeArch
OK: all build dependencies in BuildRequires
NA: proper locale handling
NA: proper use of ldconfig
NA: relocatable packages need rationale
OK: package owns all created directories
OK: no duplicate listings in %files
OK: permissions on files
OK: %clean section
OK: consistent use of macros
OK: code or permissible content
NA: large documentation in -doc subpackage
OK: nothing in %doc needed at runtime
NA: header files in -devel
NA: static libraries in -static
NA: Requires: pkgconfig
NA: .so files in -devel
NA: -devel requires main package
OK: no libtool archives
NA: proper installation of desktop file
OK: does not own files/dirs owned by other packages
OK: clean at start of %install
OK: all filenames are valid UTF-8

SHOULD items:
NA: ask upstream to include license file
NA: provide translated summary and description
OK: package builds in mock (only tried Fedora 11 x86_64)
??: package builds into binary RPMs on all supported arches (did not check)
OK: package functions as described (only able to test lightly)
OK: sane scriptlets
OK: subpackages require main package
NA: placement of pkgconfig files
NA: file dependencies

Footnotes:
[1] %doc also includes LICENSE_TESTS.txt, which seems odd, since the tests are neither run nor included in the binary package.

[2] With regard to comments #1 and #3, note that there have been more CVS checkins (in 2006!) since the 1.1.4b tag, and the log entries for those checkins refer to version 1.2-RC1.  There have been no messages to the user or dev mailing lists since 2007.  Is upstream dead?

Here are a few more changes I would like you to consider.  I won't block the review on any of these, but I think they are worth considering.
1. Make the -javadoc subpackage be noarch.
2. Add the doc subdirectory to %doc.
3. Make an -addons subpackage to hold (parts of) the addons/java subdirectory.  This may be more trouble than it is worth.  I'll leave that judgment call to you.
4. Make a -samples subpackage to hold (parts of) the src/java/samples subdirectory.  Ditto #3.

John, if you still want to submit this package to Fedora, please respond within the next week.

Due to no response from the submitter, I am closing this bug.

*** This bug has been marked as a duplicate of bug 1992757 ***