0004560: /opt/csw/sbin/alternatives not installed in sparse zone

Notes
(0008309) phil (reporter) 2010-10-01 19:00	I'm afraid this does not sound like it could possibly be a bug in the package. It is most likely a bug in the way you have done your sparse zone setup. A side note: you did not mention which of your filesystems are "pkg-inherit-dir", or any other details of how you handle /opt/csw in your sparse zones.

(0008310) jh (developer) 2010-10-01 20:19	recreate instructions: pkgutil -i sudo zonecfg -z test create -t SUNWdefault set zonepath=/export/zones/test commit exit zoneadm -z test install zoneadm -z test boot zonelogin -C test pkgchk CSWalternatives

(0008311) phil (reporter) 2010-10-01 20:29	Your test output, and what you are complaining about, would appear to only partially overlap. your adding of the "sudo" package would seem to be irrelevant. The missing factor I'm seeing here, is whether CSWalternatives is properly installed in your global zone. please do, in the global zone: ls -l /opt/csw/sbin/alternatives pkgchk CSWalternatives pkgparam CSWalternatives VERSION

(0008312) jh (developer) 2010-10-01 21:48	Yes it's only a partial overlap but I discoverd it that way. Since sudo has no symlinks in sparse zone. ls -l /opt/csw/sbin/alternatives -rwxr-xr-x 1 root bin 9757 May 17 18:05 /opt/csw/sbin/alternatives pkgchk CSWalternatives <-- exit 0 pkgparam CSWalternatives none / Europe/Berlin /sbin:/usr/sbin:/usr/bin:/usr/sadm/install/bin /usr/sadm/sysadm all CSWalternatives alternatives - an implementation of linux-style alternatives choice mgr 1.0,REV=2010.05.21 system http://www.opencsw.org [^] written and packaged for CSW by Philip Brown phil@opencsw.org http://www.opencsw.org/bugtrack/ [^] cswalternatives v1.0 CSWalternatives /var/sadm/pkg/CSWalternatives/save

(0008313) phil (reporter) 2010-10-02 01:13	This is really odd. It was a known problem that symlinks might behave oddly in sparse zones. But I had not previously seen that "regular" files were not properly copied. I have a hunch that if you had added the packages AFTER zone install, they would come out okay. but for some reason, solaris is not behaving properly on duplicating non-SUNW packages during "zoneadm install". However, reguardless, I should also mention that we only fully support /opt/csw in sparse zones, as type "inherit-pkg-dir". as mentioned in our recently updated page on sharing zones. For just this sort of reason. http://www.opencsw.org/use-it/sharing-optcsw [^] I just tested things the way you suggested, and saw the problem. I then redid my steps, but this time defined /opt/csw as inherit-pkg-dir, and it worked fine.

(0008314) phil (reporter) 2010-10-02 01:28	PS: I did some more testing: i tried WITHOUT inherit-pkg-dir, and noticed that the console of the zone was prompting me for some info. I entered the info, let it reboot, etc, etc... and THEN /opt/csw/sbin/alternatives appeared as a proper file in the zone. So you may have just been checking prematurely. But even given that, you should change your configuration of /opt/csw in the zone, to be inherit-pkg-dir, if you are going to be pkgadd'ing packages from the global zone.

(0008315) jh (developer) 2010-10-02 10:00	Just because you installed WITHOUT inherit-pkg-dir doesn't mean the bug is fixed. And closing the bug before I can confirm this is not the best way to deal with bugs. So I reopen the bug. I don't want to inherit /opt/csw as I want to install diffrend stuff in diffrend zones and don't want to have all that in the gobal zone either. For me thats a vaild use case. On a side node. I did a zlogin -C and did answer all the questions and rebooted and so on.

(0008322) jh (developer) 2010-10-02 18:35	Ok since you decline to even consider that this might be a bug since it looks like I run a configuration that is supported it should be put somewhere clear readable that using this kind of configuration is not supported.

(0008323) phil (reporter) 2010-10-02 19:41	It already is documented on our website. If you have a suggestion on a specific location where an additional reference would be appropriate, please let us know. As documented on the page I referenced above, your mixed use of pkgadd is a violation of basis consistency at the sysadmin level. If you are "inheriting packages from the global zone", then you should mark the relevant directories as "inherit-pkg-dir". That's what it's for. If you want to install packages locally for a directory... then great! Install packages locally only, for that directory in that zone. Just dont mix and match. Pick one strategy and be consistent about it, for that zone. Then these problems wont come up. I will also point out, that this is not a bug in "our" packages. This is an annoyance of how pkgadd works in Solaris, when you do global pkgadds. I'm not refusing to fix a bug in our package - I'm just informing you about how Solaris works. If you disagree with these statements, I welcome you to make a technical level comment on how specifically we can "fix" this issue.

(0008354) jh (developer) 2010-10-05 20:39	Ok did some more digging. Funny thing is that I packaged the package with gar. Using this as a reference: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/alternatives/branches/alternatives-gar [^] The package created with gar does not have the bug: http://buildfarm.opencsw.org/~jh/alternatives-1.0,REV=2010.10.05-SunOS5.9-all-UNCOMMITTED.pkg.gz [^] It might be that the gar Version does depend on common. Not sure though if thats the only reason.

(0008356) jh (developer) 2010-10-06 10:33	sure: orginal version: http://paste.pocoo.org/show/271633/ [^] gar version: http://paste.pocoo.org/show/271634/ [^]

(0008357) jh (developer) 2010-10-06 10:41	One more thing. I added the dependence to CSWcommon in the original package via pkgtrans. Might have done something wrong but since it produced the same error I guess not. So it's not a dependence problem I think.

(0008358) phil (reporter) 2010-10-06 19:21	Thanks. Fyi I deleted my comment from my other account asking you to post those two pkginfo outputs, 'cause i was sick of getting dup emails of things :) (anoying that I didnt see a way in mantis to turn off email cc's for that acct. oh well) Sooo.. I noticed Two things: 1. the gar version is CATEGORY: application but other one is category system. I wouldnt think that should matter, but... maybe experiment later. 2. the gar version shows FILES: 12 installed pathnames 2 shared pathnames whereas the regular "as-shipped" version does not. It only shows 3 files installed. Its kinda like you only installed the normal version to global zone, but you installed the gar version "fully". Which makes me wonder if you somehow installed the currently released version with pkgadd -G. Perhaps you can manually install the current version in global zone again by hand, making sure to NOT use -G, and see if things suddenly look good?

(0010543) pfelecan (manager) 2013-08-25 15:27 edited on: 2013-08-25 15:28	This is too old. If confirmed pleas re-open.

(0010547) dam (administrator) 2013-08-25 21:42	Peter, if this was opened against Phils implementation it can probably be closed, otherwise we should add a note to the alternatives implementation that it is not sparse-zone capable and probably print a warning when the package is installed in a sparse zone.

OpenCSW Bug Tracker