Kent Watsen writes: > True, but one can also hope that Xvm and its dependencies will stabalize some > day (glass half full)
;-} > > And this document: > > > > http://www.opensolaris.org/os/community/security/files/minimization-support-rules-ext.pdf > > > According to this document, my installation would be unsupported - not > because I add pacakges, but because I don't install on the dependencies > when I do. For instance, the Java runtime depends on XWindows and since > my server is headless (console-access only), I skip it... Right. The problem is that it's not possible to discern the nature of the dependency from the packaging information alone. Some dependencies are "hard," meaning that omitting that package will cause certain failure. Others are "softer," in that only certain usages or options will be affected. There are some pretty deep and complex problems buried under here. One is a combinatorial problem: it's really not feasible to run each of the thousands of discrete combinations of installed packages through testing, and we generally limit ourselves to verification of the metaclusters. If you're cooking your own combinations, you're a test pilot, because it's entirely likely that nobody has ever tried that combination before. In addition, the nature of dependencies between packages is so varied -- it's not just simple what-links-with-what, but also scripts that may invoke utilities from other packages, calls to system(3C) and exec(2), plug-ins loaded with dlopen(3C), configuration and data files read by any of a number of different means -- that it's not possible to generate or validate dependencies in any automatic fashion. We rely on individual developers to get these right, and they're human. Certainly, if there's a problem, you should report it as a bug, and the maintainer of that code should fix it, but the further you stray from the common scenarios, the more your fate is in your own hands. > All this put together, I think that I might have to skip Live Upgrade > altogether and do it on my own using the following strategy: The "not supported" statement effectively means that we don't know (a priori) whether that configuration will work, given that there are missing dependencies. It should not mean that LU specifically fails to function. (It _could_ mean that, if there's some unusual dependency between the packages, but it seems a bit far-fetched.) > 1. do a fresh install of latest SUNWcreq into a DomU > 2. pkgadd Xvm, python, etc. and configure as needed > 3. copy result onto a spare compact flash > 4. reboot system using new CF > > > Of course, I'd rather not, but what other option I have? This is slowly starting to sound like a flar(1M) configuration ... It also sounds a bit like the installer image that the Indiana folks have built. If you haven't checked out their work, you may want to. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
