Glenn Brunette writes: > This actually hits on a similar request that I have (but for different > reasons). I would like a stable interface from which I could tell > the update revision of a system.
We have no such thing. It's not clear to me how such a thing would work. Suppose someone installs only the KJP corresponding to U5 on a U4 system -- is that now U5 or U4 or U4++ or something else entirely? If that returns U5, then suppose someone installs a U5 patch not dependent on the KJP onto a U4 system. Is that still U4? What determines U5-ness? If it's dependent on the upgrade process itself, and none of the above would return the answer "U5," then suppose someone installs all of the patches for U5 and then installs/removes packages to make the system equivalent to one that had been upgraded. Is that now "U5" or is it still something else? Does it make any sense that you can have arbitrary (and improper) subsets of bits on the system and yet you're insisting on returning an effectively scalar result? > I have a very large government customer who (as part of their security > configuration hardening and assessment) process have a very real need > to detect OS version and update levels so that they can determine which > actions/checks to apply. You can get the OS version from uname and the list of patches installed from patchadd. > assumptions about how the system was installed/maintained). For > example, is the feature not present or has it been removed or simply > not installed? Is there some difference between those things? That sounds like the realm of metaphysics to me ... if bits aren't present, the "why" question seems much less interesting. How can the system necessarily know what features _could_ potentially be installed but aren't there? Isn't that "everything?" If you've installed something and then removed it, would that be different from never having installed it in the first place? (If it is, doesn't that indicate a bug in the removal process?) Perhaps most importantly: how can you use that information? What would you do differently if something had once been installed that you wouldn't do if it had never been installed? > Also, the existence of some features also can not be > easily tested using automated tools without imposing a great burden > on the tool developer. That sounds like a bug that should be fixed. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> 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 _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
