> How do I install such a package in an alternate root? -R is currently not doable. Believe me, I've been thinking about how to solve that problem, since I'd like to have my existing System V Oracle packages be installable via a JumpStart profile.
Need I write more? One possible solution would be to have separate i86pc and sparc install servers, and the server would have to be the lowest common denominator revision of Solaris, so that code could be run on the alternate root. However, the drawback is probably obvious: it's the lowest common denominator revision of Solaris, that's the problem. Again, technically doable, but architecturally problematic, because it's not a clean solution. > Or are such packages only installable on a running > system? Currently, there is a checkinstall script that prevents installation in an alternate root with an error code (ECANCELED) and outputs a corresponding message, that the package is not installable in an alternate root. In practice, the way sun customers have solved this issue is to have developed their own software deployment servers. I've seen it all: distributions over Tivoli, over SSH, ... the packages are installed directly on the system, so packages supporting installations into an alternate root were never an issue. The customers worked around it without even knowing it (NFS is strictily forbidden, because it is deemed to be insecure). > Designing features into the packaging system that are > unusable > in any context but a live install on a properly > configured > system is a major source of breakage. Maybe, but that is not for you to decide; the system engineers in the field first and foremost, and the sysadmins "in the trenches" should have the last say what happens with their systems and how. You're trying to be the brains for them, and think for them, and nothing good can come out of that. > It is a requirement that the packaging system be able > to > install packages onto an alternate root. It is not a > requirement > that the packaging system be Turing complete, or that > you > can use it as a remote execution framework. Says who? You really should send a group of people from the IPS team to do a field study on how your biggest customers have been using, and want to use the product. Please don't try to guess what they do and do not want, and what is and is not a requirement. > You can implement this w/ actuators in IPS; it will > require > a SMF service to be running to handle your > post-installation > tasks. Note that packages built this way will > actually work > on alternate root install, with Oracle running once > that > environment is booted. The problem is, the server(s) onto which software is installed might already be running. In production. You cannot possibly expect that a cluster of servers running SWIFT transactions between Europe and the U.S., or any other financial software or mission critical software, must be rebooted in order to have the database automatically start! -- This message posted from opensolaris.org _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
