Danek Duvall wrote: > On Wed, Feb 27, 2008 at 12:46:01PM -0500, Kyle McDonald wrote: > > >> The S10 update however, I have had to use, as my finish scripts have needed >> to change for didfferent updates: >> >> 1) SMF appeared in an update release if I recall correctly. ZFS did too, >> but I don't think that mattered to me (yet - ZFS boot will.) >> > > SMF was in S10 FCS, but yes, ZFS came into an update. > > 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. I don't see a problem using that info to let my Jumpstart scripts work differently. If I was creating each and every line of the JS profile programatically, then yes I suppose I could be checking the Product directory for the presence of each package before I wrote the line to add or remove it. But that would be so much more work. I'd have to start parsing the meta files that describe the clusters, and the SVR4 pkg data to find the dependencies. Yuck.
Right now, for a new Update I run it as if it was the previous one. See what errors I get during install for partition sizing, package dependencies, and in my Finishscript. Then I go and update the profile sections that will be used for that release to accomodate the chagnes I want to make for those issues. Some changes I may be able to make at a level that applies to all releases (making a partition bigger never hurts.) other changes (selecting a package I want that was added in only in the latest release) might only apply to this release. >> To add to this, I would *love* it if 'uname' or something similiar could >> just have an executable way to provide this info. >> > > Again, this is very much the wrong test. > > Maybe, see the next comment. >> I'm sure there's a reason, but I've always wondered why uname -r doesn't >> return 5.10.4 for S10u4. >> > > It's not a micro release. It's an accumulation of patches. Indeed, it's a > non-linear accumulation of patches, so mapping a feature test onto a linear > number is decidedly not going to work. > > Maybe, *inside* Sun where there are all different combinations possible. Outside Sun, It's a "Release" that is fixed, with known unchanging content. At install time, there are only very specific 'releases' available. Which for all intents and purposes *are* linear. (UNless you mean something different by linear than I'm reading.) >> It seems I can't stop talking to myself. ;) >> > > It's okay. Now we know you're crazy. ;-) > > >> Especially since installing pkgs from network IPS repositories will >> probalby make it impossible for me to peek inside the SUNWsolnm package :) >> > > True, but you'll still be able to discover package names, path names, and > possibly more, depending on what we end up Committing to. > > But how will I figure out that I'm installing from my s11u1 repository(media image really), and not my s11ga one, or my s12ga one? I will have several machines always configured to boot and Install automatically. Some will be configured to install SX_uA, others SX_uB, Others SY_uC. The Jumpstart or AI begin script will be the same in all cases, and will need to figure out which of the profile sections are the proper ones for the host being installed. Currently I only configure what to boot/install in one place (either DHCP/Grub, or /etc/bootparams) and the Begin script goes from there. I get the feeling that many of you are really excited about these constantly evolving repositories that anyone can connect to and update a running machine from at any time. That's great for the single user development machine. For me and many others, that won't ever be used. I don't see any reason not to continue to use (the equivalent of) separate fixed installation images on the installation server for each 'Release'. Those may be separate repositories created when each release becomes available. But those repositories won't ever be updated or changed once created. I won't update. I might upgrade (live, snap, or traditional) but only under extreme conditions and I won't like doing it. Most of the time I will take advantage of my totally reproducible, tested Jumpstart config to wipe and reinstall the machines to a known state. I generally refrain from making admin changes local to the machine, or installing patches even. Instead I reconfigure the Jumpstart to make those changes or install those patches every so often, and then re-install the machines. 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. -Kyle
