Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=456280 --- Comment #4 from Victor G. Vasilyev <victor.vasilyev@xxxxxxx> 2008-08-22 07:56:46 EDT --- The third release is prepared for review. Spec URL: http://www.netbeans.org/files/documents/210/2046/ini4j.spec SRPM URL: http://nbi.netbeans.org/files/documents/210/2145/ini4j-0.3.2-3.fc10.src.rpm FYI a page with all resources related to the NetBeans here: http://nbi.netbeans.org/servlets/ProjectDocumentList?folderID=267 (In reply to comment #3) > I'm having trouble understanding why this package uses alternatives at all. - Ability to switch on the alternative implementations is removed. I agree. Probability to have an alternative implementation of the ini4j on the Fedora platform is very low if only somebody won't recompile the project sources via GCJ. > I have to say, the amount of macro use in this spec is... well... let's just > say it makes things pretty hard to read. - All macroses reflecting a folders layout of the project are removed. I agree it was noise in this case. Now, there are no user-defined macroses in the spec. I hope the spec is readable now. > ... you need to be be consistent and use %{__install} as well. - The %%{__install} macro is used everywhere instead of the install command. > You do not need to have explicit scriptlet dependencies for /bin/sh. - Explicit scriptlet dependencies for /bin/sh are removed. > You shouldn't own /etc/maven/fragments or /usr/share/maven2/poms; they are > owned by jpackage-utils. - Owning of /etc/maven/fragments/ini4j is removed. But, now the rpmlint shows a warning: ------------ $ rpmlint ini4j-0.3.2-3.fc10.noarch.rpm ini4j.noarch: W: non-conffile-in-etc /etc/maven/fragments/ini4j 1 packages and 0 specfiles checked; 0 errors, 1 warnings. ------------ And, I can't remove owning of /usr/share/maven2/poms due to RPM build errors: Installed (but unpackaged) file(s) found: /usr/share/maven2/poms/JPP-ini4j.pom BTW, the example http://fedoraproject.org/wiki/Packaging/Java#maven_2 recommends to have this owning. > Is it not possible to run the tests at build time in a %check section? Yeah, it will be better to have the tests, but it requires a set of extra packages. I guess, it will be serious overhead if the these packages will only provided to test the ini4j package. Please note, only the junit package in fc10 is meet with the project requirements. Also, please note, that the ini4j package doesn't have any patches against the original Java code. Therefore, there is no need to have the tests for investigating any regressions. Nevertheless, to be sure that all is OK I've done a test to proofing of assumption that content of the target JAR generated in the scope of the package is byte-to-byte the same as content of original JAR - http://downloads.sourceforge.net/ini4j/ini4j-0.3.2-bin.zip The test has shown only expected differences in the following files: * META-INF/MANIFEST.MF - some informational values are changed * META-INF/maven/org.ini4j/ini4j/pom.properties - the build date is different * META-INF/maven/org.ini4j/ini4j/pom.xml - some lines are commented out according to the specified patch * org/ini4j/PreferencesBean$1.class and org/ini4j/PreferencesBean.class - the JDK 1.6.0_03 has been used in the original project, but it has a bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6520152 On the other hand, the OpenJDK 1.6.0 will be used to compile the classes in the scope of the package and the OpenJDK is free from this bug. So, I can say that the JAR files are the same, and, moreover, from viewpoint of the Java specifications the JAR file for Fedora is better than original one. :-) Also, I think, we can rely on the unit test results obtained in the scope of the project. > I see a bunch of commented out dependencies which suggest runtime dependencies > for the unit tests, which confuses me since generally tests have no impact on > the final packages. There are several solutions to provide the tests, including a separate subpackage that will have these dependencies at the run time. Such solution lets to test an implementation after installation into the real run-time environment. I've provided the info about dependencies only to show what will be need if somebody decide to turn on the tests, but if you feel that it is redundant or misleading info then I can remove it at all. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review