0003760: Package contains file to be installed in /usr - doesn't work in a sparse zone

Notes
(0006409) bonivart (developer) 2009-07-08 14:07	Your "crappy workaround" is the real solution, that's how Sun designed class action scripts, they are always in /usr/sadm/install/scripts. Why is that a problem? Install once globally and run in all zones. It's noted in the wiki: "Also note that class action scripts are installed in /usr/sadm/install/scripts so if you run a sparse zone you need to install cswclassutils from the global zone." http://wiki.opencsw.org/cswclassutils-package [^]

(0006410) tlecomte (reporter) 2009-07-08 14:16	Thanks for your reply. I should have read the wiki before posting. I'll leave it in the global zone.

(0006415) gadavis (reporter) 2009-07-08 19:18	I would like to add to this discussion a bit: Often my sparse root zones run a wildly different selection of packages than those of the global zone. In order to install new ones, I have to run pkg-get -fu inside the sparse root zone. It's tough to trigger a package upgrade of a package installed in the global zone from the non-global zone. Due to the inflexibility of pkg-get (which is listed on opencsw.org as the preferred package management tool), I can't just periodically run an upgrade of CSWclassutils from the global zone to ensure that my sparse-root zones will actually work. If I run "pkg-get -fu", it will trigger an upgrade of a bunch of packages that I really don't want upgraded right then and there. I've brought down our web server several times due to an automatically upgraded apache2 package or some dependent libraries with incompatible options or binaries. A solution needs to be devised that works properly in non-global zones and allows them to have different packages installed than what live in the global zone. This used to work until CSWclassutils started putting files in /usr.

(0006416) bonivart (developer) 2009-07-09 14:50 edited on: 2009-07-09 14:53	Cswclassutils is not updated frequently and it never changes functionality, only adds or fixes bugs so it's not critical to always keep it updated. As far as I know cswclassutils is the only package installing something outside of /etc/opt, /var/opt and /opt/csw and it's because of Sun's design of how class action scripts work. About pkg-get being "preferred", I wouldn't agree about that as being the author of pkgutil. :-) If you run "pkgutil -u cswclassutils" (in the global zone) it will only update cswclassutils since it doesn't have any deps. I'm sure pkg-get can do the same if you want to stay with that. I will also add a --nodeps option to pkgutil to make sure only what you specify will get installed/updated. If cswclassutils needs an update and you can't update it from the global zone immediately you can exclude it when you run installs/upgrades in your sparse zones: # pkgutil -u -x CSWcswclassutils The above example will update all packages except for CSWclassutils.

(0006419) gadavis (reporter) 2009-07-10 21:37	OK thanks for the clarification. My statement about pkg-get wasn't intended to offend - it's what's on the general consumption web pages - http://opencsw.org/packages [^] and http://opencsw.org. [^] The improvements in pkgutil with regards to dependencies might be enough for me to make the switch on my production systems. I'll probably just end up setting up a special case cron job that automatically updates cswclassutils on my global zones just so that I know it's always up to date before I try to do package installations from my non-global zones.

(0006511) bonivart (developer) 2009-08-05 17:21	Due to design by Sun we can't fix this. Simple workaround is needed (install cswclassutil in global zone).

Relationships

OpenCSW Bug Tracker