James Carlson wrote: > Kyle McDonald writes: > >> Danek Duvall wrote: >> >>> But you shouldn't be keying off of the build number, you should be keying >>> off of the presence or absence of the feature you care about. There may or >>> may not be an interface (or a sufficiently public one) for any given >>> feature you might care about, but that's generally solvable by filing an >>> RFE (in most cases, I'd imagine that providing such an interface wouldn't >>> be a big issue, and a low amount of effort). >>> >>> >>> >> I disagree. Each Build or Update is a snapshot that is released, and >> won't change. >> > > That's not quite true. > > First of all, there are other patches that are released *between* > Updates, which means that a given installation may well be at some > intermediate point between Updates due to the installation of those > patches. > > Secondly, there's no fundamental requirement that every bit from the > "snapshot" is installed on any given system. Many things are optional > components, and it's perfectly possible for a system installed from > "Update X" that is known to contain "Feature Y" not to have any part > of Y installed at all. > Again, I aggree with you abotu determining this stuff on a running system post-install.
But during install, in a begin or finish script. When figuring out what Features are available to install on the machine, it is an indicator. It's the only indicator I have for several things that are impossible for me to test for any other way. For example, how can I test to see if the Jumpstart profile processor in the release I'm running in will accept the 'mirror' option to the filesys keyword, or if I'll have to do the SVM operations manually in the Finish scripts? That option appeared in a n S9 update I beleive. > Most importantly, we don't have any stable reference that maps version > numbers of any sort to any kinds of features. If you're depending on > these undocumented mappings, then you're depending on an > implementation artifact, just as surely as if you'd picked a random > undocumented symbol in /lib/libc.so.1 on which to hang your hat. > > Again. If I was talking about my login scripts, or some other application type processing on a running system. I totally agree with you. I don't know how you say that the mapping s are undocumented. Each new release of Solaris documents the packages that are removed or added, the changes to the jumpstart keywords are also documented as being available from some release and on, or up till some release. But when the script is a Begin script writing a JS profile specifically to be consumed by the single release that it is installing, I don't see the problem. The release isn't going to change. > Test for the feature desired, not the version. > > If possible, I might agree. How can we make it easier to test for these things? >> Now that I think of it, I'm going to want to figure out a way that once >> a machine is installed, I can disable IPS, so user/admins can't >> mistakenly use it to change the config of the machine. >> > > *sigh* > Yeah I thought about that more. That was too quick and knee jerk. Locking down the repositories the different releases are kept in however I think makes sense. I want SX_uA to always install the same way. Thats not un reasonable is it? -Kyle
