Bug ID: JDK-5083395 SUNWj5cfg missing class action script for "e" type files

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other	JDK 6
5.0u1 01Fixed	6Fixed

Starting with the fix for 4985717, the pkgmap for SUNWj5cfg added the following:

e none etc/.java/.systemPrefs/.system.lock 0644 root bin
e none etc/.java/.systemPrefs/.systemRootModFile 0644 root bin

Further digging reveals that the above two files were previously
added via the postinstall script, using the same "e none" format.

Moving from the postinstall to the regular pkgmap entry for
SUNWj5cfg exposed the "e none" to the Solaris integration
audits.

So this is not a regression, so to speak, introduced by 4985717,
but rather an existing deficiency. 

The problem was uncovered in the integration of b62 into S10:
=========================================================================
Integrating Package 'SUNWj5cfg' to s10s_wos ...

Sending item information to server for verification ...

MUSTFIX:Pkgmap_MissingClassActionScript:SUNWj5cfg(sparc): classname=none
# filetype 'e' needs class action script


Sending item SUNWj5cfg to server ...
13 blocks
11 blocks
Initializing s10/s10s_wos with SUNWj5cfg


STATUS = PASSED (Item is integrated successfully)
=========================================================================

I believe without an appropriate class action script, upgrade
will not preserve the data in those files.

Unclear whether this needs to make Tiger GA or could wait for 1.5.0_01

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.5.0_01 mustang FIXED IN: 1.5.0_01 mustang INTEGRATED IN: 1.5.0_01 mustang
28-09-2004
EVALUATION ###@###.### 2004-08-06 This isn't just a Solaris upgrade problem - it is a problem with any installation (via packages) of 1.5.0 on an existing Solaris system. With the increased use multiple instances supporting layered products (JES, JDS, to name a few internal clients), this should be fixed. The core problem is that pkgadd will blindly overwrite an existing "type e" file (in the pkgmap) unless a class action script is associated with that file. The best way to fix this is to add the class action script, but to minimize risk and impact for Tiger GA, the solution should be to simply back-out part of 4985717 which introduced this problem.
28-09-2004
WORK AROUND Save and restore the preferences files around the pkgadd.
28-09-2004
SUGGESTED FIX In ...solaris/pkgdefs/SUNWj5cfg ------- Makefile ------- 1c1 < # @(#)Makefile 1.3 04/06/10 --- > # @(#)Makefile 1.4 04/09/01 19c19,20 < $(CP) ../common/copyright depend space postinstall $(PACKAGE_TMP_DIR) --- > $(CP) ../common/copyright ../common/i.preserve $(PACKAGE_TMP_DIR) > $(CP) depend space postinstall $(PACKAGE_TMP_DIR) ------- prototype_com ------- 2c2 < # @(#)prototype_com 1.2 04/06/10 --- > # @(#)prototype_com 1.3 04/09/01 22a23 > i i.preserve 28,29c29,30 < e none etc/.java/.systemPrefs/.system.lock 0644 root bin < e none etc/.java/.systemPrefs/.systemRootModFile 0644 root bin --- > e preserve etc/.java/.systemPrefs/.system.lock 0644 root bin > e preserve etc/.java/.systemPrefs/.systemRootModFile 0644 root bin ------- pkginfo.tmpl ------- 2c2 < # @(#)pkginfo.tmpl 1.6 04/05/26 --- > # @(#)pkginfo.tmpl 1.7 04/09/01 25c25 < CLASSES="none" --- > CLASSES="none preserve" and new in ../solaris/dpkdefs/common 9: cat i.preserve #!/bin/sh # # @(#)i.preserve 1.1 04/09/01 # # Copyright 2004 Sun Microsystems, Inc. All rights reserved. # SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. # # Simply preserve the existing contents of the file. # while read src dest do if [ ! -f $dest ] ; then cp $src $dest fi done exit 0
28-09-2004
PUBLIC COMMENTS Internal development bug.
28-09-2004