Subject: | |
From: | |
Reply To: | |
Date: | Thu, 31 May 2007 01:40:30 +0100 |
Content-Type: | TEXT/PLAIN |
Parts/Attachments: |
|
|
On Tue, 29 May 2007, Glenn Morris wrote:
> FWIW, I had these links in / after an install as well (but only one on
> machine out of five so far). Looks like the culprit can only be
> java-1.4.2-gcj-compat-devel, but I can't see how.
How about this as an explanation...
$ mkdir -p /tmp/foo && cd /tmp/foo
$ ls -al
total 12
drwxr-xr-x 2 jp107 other 4096 May 28 13:16 ./
drwxrwxrwt 29 root root 8192 May 31 01:12 ../
$ ln -sf `gcj -print-file-name=include/jawt_md.h` /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/jawt_md.h
-bash: gcj: command not found
$ ls -al
total 12
drwxr-xr-x 2 jp107 other 4096 May 31 01:24 ./
drwxrwxrwt 29 root root 8192 May 31 01:12 ../
lrwxrwxrwx 1 jp107 other 59 May 31 01:24 jawt_md.h -> /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/jawt_md.h
that ln is from the postinstall scriptlett, if it gets run while gcj isn't
available it drops the bad link in . which is probably / during install.
I wonder if any scriptlet errors (during the install) get logged somewhere
useful like anaconda.log...
$ rpm -qp java-1.4.2-gcj-compat-devel-1.4.2.0-40jpp.112.i386.rpm --scripts| grep -A2 ln
ln -sf \
`gcj -print-file-name=include/jni.h` \
/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/jni.h
--
ln -sf \
`gcj -print-file-name=include/jni_md.h` \
/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/jni_md.h
--
ln -sf \
`gcj -print-file-name=include/jawt.h` \
/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/jawt.h
--
ln -sf \
`gcj -print-file-name=include/jawt_md.h` \
/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include/linux/jawt_md.h
So that explains how/why it can happen, but doesn't really provide a fix.
> This rpm seems to be broken in other ways; eg an install creates the
> directory /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/include and populates it
> with links, but they are not registered as belonging to the package, and
> are not removed by an uninstall.
It presumably adds the links in the postinstall 'cos it doesn't know what
they will point at (depends on gcj). Maybe marking them as shadow would
do the right thing on an uninstall -- but it could at least rm them
in the postuninstall since it does know the link-names...
Is there a simple way to require that package to be installed after
whatever is providing gcj (if anything)?
--
Jon Peatfield, Computer Officer, DAMTP, University of Cambridge
Mail: [log in to unmask] Web: http://www.damtp.cam.ac.uk/
|
|
|