https://bugzilla.redhat.com/show_bug.cgi?id=1022551 --- Comment #9 from gil cattaneo <puntogil@xxxxxxxxx> --- (In reply to Mattias Ellert from comment #8) > [!]: License field in the package spec file matches the actual license. > License tag says "BSD". The license text in LICENSE.html is "MIT" - same > as the other bouncycastle* packages. Done > [!]: ... though there is a missing newline at the end of the specfile This is only a your problem, is not an issues > [!]: If the package is a rename of another package, proper Obsoletes and > Provides are present. > * This package replaces the discontinued bouncycastle-tsp package (all > classes from the old bctsp are now in bcpkix) and should Obsolete it. > I am not sure whether a Provides is helpful or not. > * This package replaces parts of older versions of the bouncycastle-mail > package (some classes moved from bcmail to bcpkix) - should upgrading > bouncycastle-mail 1.46 result in both bouncycastle-mail 1.50 and > bouncycastle-pkix 1.50 being installed? (This might require that both > packages Obsoletes bouncycastle-mail < 1.47), or should this just be > ignored? Done, Obsoletes: bouncycastle-tsp < 1.47 Provides: bouncycastle-tsp = %{version}-%{release} > [!]: Requires correct, justified where necessary. > Package requires java, would java-headless be enough? > Package requires both jpackage-utils and javapackages-tools. > According to the guidelines java packages should require jpackage-utils, > not javapackages-tools. jpackage-utils currently is provided by > javapackages-tools, so currently it is the same thing, but this might > change in the future. If the jpackage-utils provides moves to a > different > package or becomes a separate package the requires on javapackages-tools > will become a dependency bloat. Or is there a runtime dependency on the > non-jpackage-utils part of javapackages-tools? javapackages-tools replace jpackage-utils, if this might change in the future we use ne tools references > [!]: All build dependencies are listed in BuildRequires, except for any that > are listed in the exceptions section of Packaging Guidelines. > Package BuildRequires both java-devel and ant. Is there a reason for > this? Guidelines says java packages should BuidRequire only one of > maven-local, ant or java-devel. Done, remove java.devel > [!]: Final provides and requires are sane (see attachments). > See above regarding jpackage-utils/javapackages-tools use javapackages-tools is fine for me and the other BC maintainer msrb > Java: > [!]: Package uses upstream build method (ant/maven/etc.) > Like upstream the installed jars are built using java 1.5, so this > is fine. > Of the various bouncycastle* packages in Fedora, bouncycastle and > bouncycastle-mail build using javac, while bouncycastle-pg and this > version of the bouncycastle-pkix build using ant with a build.xml > not included in the upstream source. I am in no position to say Which > of these methods that is closest to the "upstream build method". > For me it would make sense if all the bouncycastle* packages > were built the same way - which is currently not the case. Since > the already existing packages do not agree, I can not say "please > do as the others" - but you (and this is a collective you that > includes the maintainers and co-maintainers of all the > bouncycastle* packages) might consider harmonizing this among the > packages. Original source archive from https://github.com/bcgit/bc-java/ use gradle (...crap...) or ant ... Spec URL: http://gil.fedorapeople.org/bouncycastle-pkix.spec SRPM URL: http://gil.fedorapeople.org/bouncycastle-pkix-1.50-1.fc19.src.rpm -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review