[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-03 23:43 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0008265) phil (manager) - 2010-09-03 23:43
 https://www.opencsw.org/mantis/view.php?id=4538#c8265 
---------------------------------------------------------------------- 
Thanks for checking.

I've done some more testing, and I have replicated it myself.
Summary of behaviour:
When creating a new zone, the "zoneadm install" command would seem to go
through the package database in the global zone... NOT the filesystems...
and copy every file that is both in the database, and not in a
"inherit-pkg-dir" directory.
Files in a filesystem, but not in the pkg database, do not get copied.
The "alternatives" symlinks fit into this category.

That being said... what to do about it?
I could theoretically hack the "alternatives" scripts in nasty ways, to
register the links with a fake package. or even the CSWalternatives
package. But this does not seem clean to me.
And then there remains the issue of: SHOULD I even attempt to fix this?
It would validate a deployment method which in my opinion, will only lead
to futhre trouble eventually. I think that if someone wants fully local
package deployment to each zone, they should deploy packages locally. And
if they want global installation of packages... they should use the
inherit-pkg-dir functionality that is provided for that sort of thing!
(specifically, for /opt/csw not /etc/opt/csw).
It helps them a bunch also, avoiding needless redundant backups,etc.
All zone-local configs should now be in /etc/opt/csw anyway, and any csw
packages that dont follow this, should have a bug filed against them.

What do you think, Geoff?