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.
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 220.127.116.11, 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 18.104.22.168
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:
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.
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
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:
Looks like mona also went with the X.YrZ version format as well, which is fine
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.
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:
Looks good to me; all the complaints I had seem to be fixed now, and things
still build fine.
New Package CVS Request
Package Name: automaton
Short Description: Java finite state automata/regular expression library
Cvsextras Commits: yes
Thanks everybody. Automaton is now in rawhide and will hit F-9 soon.