[bug-notifications] [alternatives 0004538]: Symbolic links not created in new sparse-root zone

Mantis Bug Tracker noreply at opencsw.org
Fri Sep 3 00:12:57 CEST 2010

A NOTE has been added to this issue. 
Reported By:                gadavis
Assigned To:                phil
Project:                    alternatives
Issue ID:                   4538
Category:                   regular use
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Date Submitted:             2010-08-31 22:19 CEST
Last Modified:              2010-09-03 00:12 CEST
Summary:                    Symbolic links not created in new sparse-root zone
There appears to be a bug in the alternatives mechanism when creating a new
sparse-root zone on Solaris 10 systems.

I have a global zone with CSW alternatives, CSWneon, CSWsudo, and
CSWsudo-common installed. The alternatives mechanism has registered the
symlinks in the right locations and alternatives --display neon and
alternatives --display sudo work as expected.

If I then create a new non-global zone with the default inherited paths
(your typical sparse-root zone), alternatives --display whatever shows the
correct paths listed, but the symlinks are not there.

After zone creation, I have to manually force the alternatives mechanism
to install the needed symlinks by running a shell loop:

for d in `ls /opt/csw/share/alternatives`; do 
	alt=`basename $d`; 
	alternatives --auto $alt; 

Note that if I uninstall CSWsudo inside the zone and then re-install it,
the alternatives mechanism works as expected. It's only upon initial zone
creation that the alternatives symlinks do not get created.

 (0008246) phil (manager) - 2010-09-03 00:12
Part one of reply:
To have a fully local package install, without changing anything else in
your setup, you would have to do BOTH of
 - stop installing CSW packages in the global zone(or use pkgadd -G)
 - run pkgadd individually in each zone

Note, however, that using pkgadd -G is not a good solution, since sun
screwed up/orphaned the implementation. There is no pkgrm -G.  So the next
time you do pkgrm in the global(ie for an upgrade!), you will then pkgrm in
all child zones automatically!

part two of reply:
the problem is that if you are not inherit-pkg-dir-ing, then updates may
not get shared out to child zones properly. Things get copied okay
initially, when you first create a child zone.. but then things drift, I
Things get especially dangerous in a mixed mode, when you pkgadd/rm from
You have class action scripts, and/or pre/postinstall scripts running,
from the package in the global zone, that expect the same version of files
in the package, but the actual files in the child zone may not be the same

Note: I have not actually TESTED the behaviour in mixed-mode recently, but
I believe this is the source of your problems.
I think I'll go do some experimenting.

More information about the bug-notifications mailing list