Bug 394871

What you have to worry about with the upstream version is ordering.  If you turn
1.10-3 into 1.10.3, you have to be sure that upstream doesn't decide to release
1.10.1-1, which you turn into 1.10.1.1, which is "less" rpm-wise than the
existing 1.10.3.  You can work around it with Epoch:, but many people find
Epoch: distasteful and it can make dependencies difficult.

One thing that does work is to use 'r' instead of '.':

  > rpmdev-vercmp 1.10.3 1.10.1.1
  0:1.10.3-None is newer

  > rpmdev-vercmp 1.10r3 1.10.1r1
  0:1.10.1r1-None is newer

So, it's really up to you.  How much do you know about what upstream will do
with the version in the future?

I don't know what upstream will do with the version.  Thank you for the
suggestion.  I am going to take it.  Here are the new URLs:

http://jjames.fedorapeople.org/automaton/automaton.spec
http://jjames.fedorapeople.org/automaton/automaton-1.10r3-1.src.rpm

One small informal review remark:)

>rpmlint automaton-1.10r3-1.fc8.x86_64.rpm automaton-javadoc-1.10r3-1.fc8.x86_64.rpm
automaton.x86_64: W: non-standard-group Development/Libraries/Java
automaton-javadoc.x86_64: W: non-standard-group Development/Libraries/Java

There is no Development/Libraries/Java, just Development/Libraries (see
/usr/share/doc/rpm-4.4.2.2/GROUPS).

Otherwise it seems ok for me.

Thanks for the comment, Milos.  I think the group doesn't matter.  For one
thing, Fedora management has said that they don't care about the group tag
anymore; only the comps file matters now.  Also, try this: "rpm -qg
Development/Libraries/Java".  I get a couple of dozen packages listed as a
result; they all seem to be derived from jpackage.org.

Here are new versions that conform to the recently released Java packaging
guidelines.

http://jjames.fedorapeople.org/automaton/automaton.spec
http://jjames.fedorapeople.org/automaton/automaton-1.10r3-2.src.rpm

Have you tried contacting Anders about the versioning scheme ? If the issue is
explained to him, I wouldn't be surprised if he'd adopt one that's closer to the
usual major.minor.micro scheme

Thanks for the suggestion, David.  Anders is attempting to use precisely the RPM
versioning scheme; i.e., version-release.  This works great so long as he is the
only one releasing packages.  However, it doesn't work so well should I, as
Fedora maintainer, need to make a new release to fix a packaging problem or to
put in a temporary security fix.

Why don't I use exactly his versioning scheme, and append .1, .2, etc. in the
event that I need to make a release that is not tied to an upstream release? 
That is, the initial package would be automaton-1.10-3, exactly like he has it.
 If I need to make a new release before Anders does, then I'll make it
automaton-1.10-3.1, and so on.  Does that seem like a better idea, given that
Anders likes his scheme?

This discussion also affects mona, bug #436033, by the way.

Here is a new package reflecting an upstream release that fixes a bug:

http://jjames.fedorapeople.org/automaton/automaton.spec
http://jjames.fedorapeople.org/automaton/automaton-1.10r4-1.src.rpm

Looks like mona also went with the X.YrZ version format as well, which is fine
with me.

rpmlint complains only about the Group: tags, which seems to be normal for java
packages and which we don't care about anyway.

I'm pretty sure the jars are rebuilt, but the upstream source includes a
prebuilt one, so it would be best to simply delete it in %prep.

The gcj bits should all be conditionalized.

* source files match upstream:
   2af431a4c9beee99d9739d1284efa99a4b21c6bfd27059f430de6ef4574cdb56  
   automaton-1.10-4.tar.gz
* 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 included in package.
* latest version is being packaged.
* BuildRequires are proper.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
  automaton-1.10r4-1.fc10.x86_64.rpm
   automaton-1.10r4.jar.so()(64bit)
   automaton = 1.10r4-1.fc10
  =
   /bin/sh
   java
   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)

  automaton-javadoc-1.10r4-1.fc10.x86_64.rpm
   automaton-javadoc = 1.10r4-1.fc10
  =
   automaton = 1.10r4-1.fc10
   jpackage-utils

* %check is not present; no test suite upstream.  I to not know how to test this 
   package.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
X scriptlets should consitionalize the gcj 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.
* ant called properly.
* no wrapper script necessary.
X gcj not called properly; should be conditionalized.

Thanks for the review, Jason.  I now remove the prebuilt jar in the %prep
section and have conditionalized all the gcj stuff.  New versions are here:

http://jjames.fedorapeople.org/automaton/automaton.spec
http://jjames.fedorapeople.org/automaton/automaton-1.10r4-2.src.rpm

Looks good to me; all the complaints I had seem to be fixed now, and things
still build fine.

APPROVED

New Package CVS Request
=======================
Package Name: automaton
Short Description: Java finite state automata/regular expression library
Owners: jjames
Branches: F-9
InitialCC:
Cvsextras Commits: yes

cvs done.

Thanks everybody.  Automaton is now in rawhide and will hit F-9 soon.