Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: scala - Hybrid functional/object-oriented language https://bugzilla.redhat.com/show_bug.cgi?id=426867 ------- Additional Comments From geoff@xxxxxxxxxxxxxxxxxxx 2008-01-12 23:50 EST ------- Thanks for taking a look at my package, it looks like you might not have tried the latest release (5) since I fixed some of the issues you pointed out in that release. > skills to get a sponsor. Make an informal review, that is. Yeah, I know I've got to do that but my day job has been keeping me too busy lately. > Licensing: The documentation refers to a "BSD-like" license defined in the file > docs/LICENSE. It seems to be a specific scala license, not one of the "good" > ones in wiki/Licensing. I checked on fedora-legal about this (https://www.redhat.com/archives/fedora-legal-list/2007- December/msg00012.html) and got confirmation that the license is OK and to use BSD for the license tag. > > Missing build dependencies: > update-mime-database shared-mime-info (post/postun) I took the post/postun directly from http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head- 5f93ed83c968bb73b052c06ba0d7139e28f35d93 The script is such that it will not fail if shared-mime- info is not installed > pkg-config pkgconfig > svn subversion > > mock test fails on missing svn (subversion). After adding subversion it fails > with: /var/tmp/rpm-tmp.96363: line 77: clean: command not found These should be fixed in release 5 > The placement of the post/postun scriptlets at the very end is unusual. Normal > place is after the %install, why not stick to this? That's a good idea. I'm not sure how/why they ended up down there > The package includes not only the upstream source tarball, but also the binary > distribution tarball scala-2.6.1-final. This contains generated stuff (e. g., > jar files) and raises issues whether all source is included according to > wiki/Packaging/Guidelines. It definitely breaks wiki/PackagingDrafts/Java It is kind of an akward situation. As far as I can figure that is the only way to get some things (documentation, scripts, etc) for a specific release. Would you recommend to erase the binary components of the unpacked binary tarball as part of the prep to make sure that the binary components don't end up installed by the RPM? > Package contains a devel subpackage, makes no sense in a java context and breaks > wiki/PackagingDrafts/Java. devel contains a configuration file, belongs to > another (sub) package? I think that this package is a little different since it is actually a language compiler and runtime not just a library. The devel package contains the configuration to allow using scala from ant and the runtime source code (which I'm not sure about packaging, but it is included in a standard scala distribution) > Discussion: seems that java packages requires a whole lot of copying in > %install. Is this the right place, would it be better to use ant or make to > clean up the spec file, to make it look more like a normal make-based spec-file? > Is there any (other) good example of a packaged java-app out there? I think the big problem here is that most java applications/libraries do not concern themselves with installation and even if they do don't match up with the jpackage conventions. -- 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, or are watching someone who is. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review