Spec URL: http://jjames.fedorapeople.org/trove/trove.spec SRPM URL: http://jjames.fedorapeople.org/trove/trove-2.0.4-1.fc10.src.rpm Description: The GNU Trove library has two objectives: - Provide "free" (as in "free speech" and "free beer"), fast, lightweight implementations of the java.util Collections API. These implementations are designed to be pluggable replacements for their JDK equivalents. - Whenever possible, provide the same collections support for primitive types. This gap in the JDK is often addressed by using the "wrapper" classes (java.lang.Integer, java.lang.Float, etc.) with Object-based collections. For most applications, however, collections which store primitives directly will require less space and yield significant performance gains.
Any comments on the conflict between this and ESR's Trove project? http://catb.org/~esr/trove/ Is the other project sufficiently dead that this isn't an issue? Even this project's upstream seems to use "trove4j" in places.
I don't know anything about that other Trove project, but it sure appears to be dead. It's developer mailing list doesn't even exist any more. However, I'm all for avoiding name conflicts. Should I call this submission "trove4j", do you think?
*** Bug 532521 has been marked as a duplicate of this bug. ***
I'm interested in this package, Jerry are you still working on it? Some quick things: - renaming to trove4j seems reasonable (other distros did that also) - prefer %global over %define - group Development/Libraries/Java is not standard, change it to Development/Libraries - -javadoc subpackage should Requires: jpackage-utils too - would packaging lastest stable ver 2.1.0 be feasible? - as per gcj guidelines, in %%files: %if %{with_gcj} - %{_libdir}/gcj/%{name} + %attr(-,root,root) %{_libdir}/gcj/%{name} %endif
Actually, my reason for wanting this package in Fedora vanished a couple of months ago. I'm still willing to see it through if nobody else wants to so do, but if someone else is interested in maintaining, I'm happy to pass the baton. Otherwise, I'll fix the problems noted in comment 4 sometime in the next 24 hours or so.
I have a package-in-progress of version 2.1 in bug 532521 if anyone's interested -- Jerry, do you still want to package this?
Not really. The package I wanted to push that depended on this turned out to have some severe license problems. Please go ahead and take it. I'm not sure what the proper bugzilla etiquette is, though.
How reversing the "closed duplicate" direction of the two bugs? *** This bug has been marked as a duplicate of bug 532521 ***