Bug ID: JDK-4985717 SUNWj5cfg still show after pkgrm all SUNWj5* in Sol 10.

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
5.0 b57Fixed

In Sol 10 (at least b50),  after removing all the SUNWj5* packages, the SUNWj5cfg still show (pkginfo | grep SUNWj5).  I think it is because Sol 10 has SUNWj3cfg and SUNWj5cfg, that is pointing to same directory/files.

/etc/.java/.systemPrefs/.systemRootModFile
/etc/.java/.systemPrefs/.system.lock
/etc/.java/.systemPrefs
/etc/.java


After removing all the SUNWj3 and pkgadd SUNWj5cfg, I am able to remove successfully and the package didn't show.


 


###@###.### 2004-01-29


  I think this bug can reproduce only if you have fresh installation of Sol_10.  By default, Sol_10 has SUNWj3 and SUNWj5 installed.  When I pkgrm all SUNWj5, it still shows SUNWj5cfg.  Once pkgrm all SUNWj3 and SUNWj5, everything will be back to normal from this point on. 

 normal = will not see SUNWj5cfg after pkgrm

###@###.### 2004-01-29

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-rc FIXED IN: tiger-rc INTEGRATED IN: tiger-b57 tiger-rc
25-06-2004
EVALUATION ###@###.### 2004-02-04 The problem is that the SUNWj3cfg and SUNWj5cfg packages don't play nice together. They both attempt to install the same files (which is by design), but if they find the files are already present, they don't overwrite the files (which is correct), but they also don't register their interest in the files which is incorrect. The sequence: # pkgadd SUNWj3cfg # pkgadd SUNWj5cfg # pkgrm SUNWj3cfg will result in the relevant files being removed while the existance of SUNWj5cfg should have forced them to be retained. The relevant code is: CreateUtilPrefs() { if [ ! -d ${PKG_INSTALL_ROOT}${PREFS_LOCATION} ]; then $INSTALLF -c none $PKGINST ${PREFS_LOCATION} d 0755 root bin fi if [ ! -d ${PKG_INSTALL_ROOT}${PREFS_LOCATION}/.systemPrefs ]; then $INSTALLF -c none $PKGINST ${PREFS_LOCATION}/.systemPrefs d 0755 root bin fi if [ ! -f ${PKG_INSTALL_ROOT}${PREFS_LOCATION}/.systemPrefs/.system.lock ]; th en touch ${PKG_INSTALL_ROOT}${PREFS_LOCATION}/.systemPrefs/.system.lock $INSTALLF -c none $PKGINST ${PREFS_LOCATION}/.systemPrefs/.system.lock e 0644 root bin fi if [ ! -f ${PKG_INSTALL_ROOT}${PREFS_LOCATION}/.systemPrefs/.systemRootModFile ]; then touch ${PKG_INSTALL_ROOT}${PREFS_LOCATION}/.systemPrefs/.systemRootModFile $INSTALLF -c none $PKGINST ${PREFS_LOCATION}/.systemPrefs/.systemRootModFile e 0644 root bin fi $INSTALLF -f $PKGINST } In all cases, the INSTALLF shouldn't be conditional. You want to register ownership of these files to the package being installed even if some other package already installed them. This will prevent their removal until the last appropriate package is removed.
25-06-2004
SUGGESTED FIX ###@###.### 2004-05-29 Remove the dynamic registration of these files and directrory heirarchy from the postinstall script and do it unconditionally via pkgmap entries. This is not worthy of a patch to 1.4.2. Hence the sequence: pkgadd SUNWj5rt pkgadd SUNWj3rt pkgrm SUNWj5rt Will still result in the removal of these files.
25-06-2004
PUBLIC COMMENTS ###@###.### 2004-05-29 Improper registring of the SUNWj5cfg components with the package database.
29-05-2004

Duplicate :	JDK-5060074 - Package Removal (SUNWj5cfg)
Relates :	JDK-5083395 - SUNWj5cfg missing class action script for "e" type files
Relates :	JDK-5057194 - Removal of SUNWj5cfg does not remove all components it created.