Bug 394871 - Review Request: automaton - a Java finite state automata/regular expression library
Summary: Review Request: automaton - a Java finite state automata/regular expression l...
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-11-21 20:23 UTC by Jerry James
Modified: 2008-07-07 16:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-07-07 16:16:28 UTC
Type: ---
j: fedora-review+
kevin: fedora-cvs+

Attachments (Terms of Use)

Description Jerry James 2007-11-21 20:23:25 UTC
Spec URL: http://jjames.fedorapeople.org/automaton/automaton.spec
SRPM URL: http://jjames.fedorapeople.org/automaton/automaton-1.10.3-1.src.rpm
This Java package contains a DFA/NFA (finite-state automata) implementation with Unicode alphabet (UTF-16) and support for the standard regular expression operations (concatenation, union, Kleene star) and a number of non-standard ones (intersection, complement, etc.).

In contrast to many other automaton/regexp packages, this package is fast, compact, and implements real, unrestricted regular operations.  It uses a symbolic representation based on intervals of Unicode characters.

The one funny thing about this package is the version numbering scheme.  Upstream uses a version-release scheme, so this is actually 1.10-3 according to upstream.  I have converted the dash to a dot for the version number in the RPM.  If this is not acceptable, help me figure out an acceptable scheme.

Comment 1 Jason Tibbitts 2007-11-22 00:00:02 UTC
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, 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
  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?

Comment 2 Jerry James 2008-01-07 21:37:07 UTC
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:


Comment 3 Milos Jakubicek 2008-03-07 23:24:13 UTC
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

Otherwise it seems ok for me.

Comment 4 Jerry James 2008-03-11 15:08:52 UTC
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.

Comment 5 Jerry James 2008-04-18 21:44:47 UTC
Here are new versions that conform to the recently released Java packaging


Comment 6 David Lutterkort 2008-04-30 16:47:26 UTC
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

Comment 7 Jerry James 2008-05-01 19:22:48 UTC
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.

Comment 8 Jerry James 2008-06-06 16:35:21 UTC
Here is a new package reflecting an upstream release that fixes a bug:


Comment 9 Jason Tibbitts 2008-06-29 20:08:12 UTC
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:
* 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
   java-gcj-compat >= 1.0.31

   automaton-javadoc = 1.10r4-1.fc10
   automaton = 1.10r4-1.fc10

* %check is not present; no test suite upstream.  I to not know how to test this 
* 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.

Comment 10 Jerry James 2008-06-30 20:10:21 UTC
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:


Comment 11 Jason Tibbitts 2008-07-02 05:54:38 UTC
Looks good to me; all the complaints I had seem to be fixed now, and things
still build fine.


Comment 12 Jerry James 2008-07-03 03:56:25 UTC
New Package CVS Request
Package Name: automaton
Short Description: Java finite state automata/regular expression library
Owners: jjames
Branches: F-9
Cvsextras Commits: yes

Comment 13 Kevin Fenzi 2008-07-04 19:38:02 UTC
cvs done.

Comment 14 Jerry James 2008-07-07 16:16:28 UTC
Thanks everybody.  Automaton is now in rawhide and will hit F-9 soon.

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