https://bugzilla.redhat.com/show_bug.cgi?id=1022551
--- Comment #9 from gil cattaneo <puntogil(a)libero.it> ---
(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