[Bug 453119] Review Request: libvirt-java: Java bindings for the libvirt library

[bugzilla at redhat.com]

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: libvirt-java: Java bindings for the libvirt library


https://bugzilla.redhat.com/show_bug.cgi?id=453119


tibbs at math.uh.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|nobody at fedoraproject.org    |tibbs at math.uh.edu
             Status|NEW                         |ASSIGNED
               Flag|                            |fedora-review?




------- Additional Comments From tibbs at math.uh.edu  2008-07-03 21:42 EST -------
Yes, this builds.  In addition to the strange-permission complaint above (which
isn't a problem) rpmlint says:

  libvirt-java-javadoc.x86_64: W: non-standard-group Development/Documentation
which is bogus; we don't care what goes in Group:

  libvirt-java.x86_64: E: zero-length /usr/share/doc/libvirt-java-0.1.2/NEWS
There's generally no point in shipping an empty file.  Is it needed for something?

 libvirt-java.x86_64: W: unused-direct-shlib-dependency
  /usr/lib64/libvirt_jni.so.0.1.2 /usr/lib64/libxenstore.so.3.0
This just means that libvirt_jni links against libxenstore but doesn't call any
functions in it.  This is pretty common with pkgconfig files since they
maximally specify link flags; generally easy to correct by linking with
"-Wl,--as-needed" but not really a big issue as long as it doesn't result in
expanded dependencies, which it doesn't here.

The Source: tag should contain a URL to the sources:
  Source: http://libvirt.org/sources/java/libvirt-java-%{version}.tar.gz

Your BuildRoot must contain at least
%{release}.http://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag

The license looks to be LGPLv2+ to me.  None of the source files have the proper
license blocks, and so the license in the COPYING.LIB files allows us to choose
any version of the LGPL that has ever or will ever exist.

The use of gcj is only a strong suggestion but not a requirement, so I'm
certainly not going to block on it here.  My understanding is that we still have
platforms where gcj is needed, but I guess that's between you and the (rest of)
the java team.

The javadoc subpackage needs dependencies on the main package and jpackage-utils.

I'm pretty sure that test.java file isn't really useful unless it has an
existing virtual machine to talk to.  Please correct me if I'm wrong.

I have to ask: what is the point of the libvert-src zipfile?  Why would a Java
package need to include its source code?

* source files match upstream:
   c746b1f8a76bdf16c0b9eb6751fa7998712ba07788a3ab5a6b4c0842a4bb7cb4  
   libvirt-java-0.1.2.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
X build root needs at least %{release}.
X license field does not match the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete (no java files since gcj isn't called).
X rpmlint has a valid complaint (zero-length NEWS file).
X final provides and requires:
  libvirt-java-0.1.2-1.fc10.x86_64.rpm
   libvirt_jni.so.0()(64bit)
   libvirt-java = 0.1.2-1.fc10
  =
   /sbin/ldconfig
   java >= 1.5.0
   jpackage-utils
   libvirt >= 0.4.0
   libvirt.so.0()(64bit)
   libvirt_jni.so.0()(64bit)
   libxenstore.so.3.0()(64bit)

  libvirt-java-devel-0.1.2-1.fc10.x86_64.rpm
   libvirt-java-devel = 0.1.2-1.fc10
  =
   libvirt-devel >= 0.4.0
   libvirt-java = 0.1.2-1.fc10
   libvirt_jni.so.0()(64bit)
   pkgconfig

  libvirt-java-javadoc-0.1.2-1.fc10.x86_64.rpm
   libvirt-java-javadoc = 0.1.2-1.fc10
  =
X no dependencies on jpackage-utils or main package.

* %check is not present; test code can't be run in the buildsys.
* shared libraries installed:
   ldconfig is called properly.
   unversioned .so links are in the -devel package
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* scriptlets OK (ldconifg).
* code, not content.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* pkgconfig files in the -devel package; pkgconfig dependency included.
* no static libraries.
* no libtool .la files.
* no pre-built jars
* single jar, named after the package
* jarfiles are under _javadir.
* javadocs are under _javadocdir.

-- 
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.