[Bug 433070] Review Request: java-1.6.0-openjdk - The OpenJDK 1.6.0 runtime environment

Fri Mar 7 16:58:30 UTC 2008

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: java-1.6.0-openjdk - The OpenJDK 1.6.0 runtime environment

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

------- Additional Comments From fitzsim at redhat.com  2008-03-07 11:58 EST -------
rpmlint output:

$ rpmlint ~/Desktop/java-1.6.0-openjdk-1.6.0.0-0.1.b06.fc9.src.rpm 
java-1.6.0-openjdk.src:60: E: hardcoded-library-path in %{_prefix}/lib

Fixing this is hard.  It involves making jpackage-utils multilib
compatible.  Work is progressing toward that goal but it is blocked on
this rpm bug:

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

Work is also proceeding on fixing that bug, but slowly.

java-1.6.0-openjdk.src:299: E: configure-without-libdir-spec
java-1.6.0-openjdk.src:314: E: configure-without-libdir-spec
java-1.6.0-openjdk.src:321: E: configure-without-libdir-spec

None of these configured codebases -- IcedTea, GNOME Java Access
Bridge, Mauve -- is installed.  There may be no harm in adding
--libdir=%{_libdir} to satisfy rpmlint though.

java-1.6.0-openjdk.src: W: patch-not-applied Patch1: java-1.6.0-openjdk-win32.patch
java-1.6.0-openjdk.src: W: patch-not-applied Patch2: java-1.6.0-openjdk-jhat.patch

Fix.

java-1.6.0-openjdk.src: W: strange-permission generate-fedora-zip.sh 0775

Fix.

$ rpmlint
/notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-1.6.0.0-0.1.b06.fc8.i386.rpm 

java-1.6.0-openjdk.i386: E: non-standard-dir-perm
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/zi/Australia 02755
...

Fix and add FIXME comment saying we need to fix this upstream.

java-1.6.0-openjdk.i386: W: file-not-utf8
/usr/share/doc/java-1.6.0-openjdk-1.6.0.0/THIRD_PARTY_README

Fix and add FIXME comment saying we need to fix this upstream.

java-1.6.0-openjdk.i386: W: incoherent-version-in-changelog 1:1.6.0.0-.1.b06
1:1.6.0.0-0.1.b06.fc8

Fix.

java-1.6.0-openjdk.i386: E: useless-explicit-provides jdbc-stdext

I checked Rawhide: it's safe to remove this line and the explanatory
comment:

Provides: jdbc-stdext = %{epoch}:%{version}

since Fedora packages refer to either the versionless jdbc-stdext
provides or the JDBC API version.  But can you add the leading 0: to
the 3.0 provides?

java-1.6.0-openjdk.i386: E: binary-or-shlib-defines-rpath
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/keytool
['$ORIGIN/../lib/i386/jli', '$ORIGIN/../jre/lib/i386/jli']
...

rpmlint bug:

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

java-1.6.0-openjdk.i386: E: file-in-usr-marked-as-conffile
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/security/cacerts
...

These should probably eventually be replaced by symlinks somewhere
into /etc, but we'll need to discuss this with OpenJDK upstream
developers.  Can you add a FIXME comment in the %files section saying
so?

java-1.6.0-openjdk.i386: W: uncompressed-zip
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/jsse.jar
...

rpmlint bug:

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

$ rpmlint
/notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-devel-1.6.0.0-0.1.b06.fc8.i386.rpm

java-1.6.0-openjdk-devel.i386: W: file-not-utf8
/usr/share/doc/java-1.6.0-openjdk-devel-1.6.0.0/THIRD_PARTY_README

Fix.

java-1.6.0-openjdk-devel.i386: E: non-standard-dir-perm
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/include 02755
...

Fix.

java-1.6.0-openjdk-devel.i386: W: dangling-relative-symlink
/usr/lib/jvm-exports/java-1.6.0-openjdk java-1.6.0-openjdk-1.6.0.0

Fine for now, since devel package requires base package which provides
the fully-versioned directory.  In the future we may want to eliminate
these fully-versioned directories.  They're slightly irritating
because rpmdiff can't handle them properly, and also because they're
simply redundant.

java-1.6.0-openjdk-devel.i386: E: binary-or-shlib-defines-rpath
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/bin/jsadebugd
['$ORIGIN/../lib/i386/jli', '$ORIGIN/../jre/lib/i386/jli']
...

rpmlint bug, see above.

java-1.6.0-openjdk-devel.i386: W: uncompressed-zip
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/lib/tools.jar

rpmlint bug, see above.

$ rpmlint
/notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-demo-1.6.0.0-0.1.b06.fc8.i386.rpm

java-1.6.0-openjdk-demo.i386: E: non-standard-dir-perm
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/demo/jvmti 02755
...

Fix.

java-1.6.0-openjdk-demo.i386: E: invalid-soname
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/demo/jvmti/mtrace/lib/libmtrace.so
libmtrace.so
...

These are dlopend, so their SONAMEs are fine.  rpmlint should probably
recognize that these are not in standard library location and assume
they're dlopened.  Here's the bug:

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

$ rpmlint
/notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-javadoc-1.6.0.0-0.1.b06.fc8.i386.rpm

java-1.6.0-openjdk-javadoc.i386: E: non-standard-dir-perm
/usr/share/javadoc/java-1.6.0-openjdk/api/java/util/jar 02755
...

Fix.

$ rpmlint
/notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-src-1.6.0.0-0.1.b06.fc8.i386.rpm
java-1.6.0-openjdk-src.i386: E: only-non-binary-in-usr-lib

This error probably shouldn't apply to subpackages:

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

$ rpmlint -i
/notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-debuginfo-1.6.0.0-0.1.b06.fc8.i386.rpm

Lots of errors.  I'll assume that the debuginfo subpackage isn't
expected to be rpmlint-clean.

MUST

- package naming

  The package is not named according to the Package Naming Guidelines.
  It is named according to JPackage naming conventions

- spec file name matches base package name

- package follows Packaging Guidelines

- acceptable license

- license field matches actual license

- license file marked as %doc in base package

- American English

- spec file is legible

- didn't check md5sum

  The tarball is a snapshot from the IcedTea Mercurial repository.  It
  is not released so I can't check the md5sum.

- package builds on x86

- package should build on all architectures (IcedTea 7 does)

- all build requirements listed

- no locales

- no shared libraries

- not relocatable

- owns all directories

  I believe so.  To be clear about this though, I'd prefer not to use
  the -f option to the base and demo files sections, and instead list
  all files explicitly.  This is more verbose but less error prone.
  This is not a blocker for acceptance of this package though -- we
  can do this in a subsequent Rawhide update.

- check no duplicate files

  I'm seeing these warnings:

  *** WARNING: identical binaries are copied, not linked:
        /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/bin/keytool
   and  /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/keytool

  Can you add a FIXME comment to look into hard-linking these instead?
  (symlinking won't work since relative directories are calculated
  based on these tools' fully-expanded locations.)

- correct permissions

  No.  See rpmlint output.

- clean section

- consistent macro use

- package contains code

- javadoc subpackage

- runtime doesn't need docs

- header files in -devel package

  The java-1.6.0-openjdk-devel subpackage isn't a typical Fedora devel
  package.  Instead "-devel" here means "SDK tools".

- no static libraries

- no pkgconfig files

- no suffixed libraries

- devel subpackage requires base

- no libtool archives

- no desktop files

- no dual directory ownership

- buildroot removed at start of %install

- filenames valid UTF-8

SHOULD

- license text included

- no summary translations

- didn't try building in mock

- didn't try building on non-x86 architectures

- basic functionality works

  Yes. "Hello World" compiles and runs

- sane scriptlets

  Lots of use of alternatives, but warranted.

- subpackages require base package

  All subpackages except the javadoc subpackage require the base
  package.

- no pkgconfig file

- owns its own directories

  Yes.  Requires jpackage-utils for lower-level directories.

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