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

[Mantis Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://www.opencsw.org/mantis/view.php?id=4538 
====================================================================== 
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-04 02:16 CEST
====================================================================== 
Summary:                    Symbolic links not created in new sparse-root zone
Description: 
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; 
done

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

---------------------------------------------------------------------- 
 (0008270) phil (manager) - 2010-09-04 02:16
 https://www.opencsw.org/mantis/view.php?id=4538#c8270 
---------------------------------------------------------------------- 
Mmm, yeah CSWclassutils is unfortunately a special, somewhat ugly case.
The good news is, that one doesnt have any postinstall scripts, etc. :)

For everything else though, sounds like zone local is what you need, to
ensure that everything works 100% as expected, when you create a new zone
without cloning.

OR.... you would do that special case re-running the alternatives script
for new zones. sigh.

Extra background: This could be "fixed" by installf getting called when
symlinks are created... but installf requires a package to associate the
symlinks with in the pkg database. which package would I use; itself, or
the top level alternative being linked?
Also, I'm trying to keep the "alternatives" script itself, portable. So I
dont want to hardcode "CSWxxx" stuff in it. 
Hmm.. although I did have to hardcode /opt/csw in it anyway....
I MIGHT do that after all, I suppose.

Another approach might be the other class-action wrappers, which in theory
could be adjusted to register the symlinks when they call it, at pkgadd/rm
time. Except that it would not be registered when 'alternatives' was called
directly.