On Fri, May 16, 2008 at 07:11:03PM -0700, Paul B. Henson wrote: > > > However, after installing the update, nothing seemed to have changed. > > > > Does it still consider itself upgradable? > > No, that did indeed change, but nothing tangible seems to have happened > other than the "entire" package has a slightly newer version number and no > longer lists an upgrade available. It's just not clear what that upgrade > was intended for or accomplished.
Yeah, we're going to have to improve the user experience here a bit. I believe that normally, you'd freeze the high-level incorporations (so they wouldn't move forward at all), and then "install" or "image-update" at will to get the latest versions of everything else within the constraints of those incorporations. Upgrading the incorporation simply moves the constraints on everything else forward, but won't do anything on its own. > > rudimentary version of the same). An incorporation is a package that > > contains dependencies which constrain the forward (upgrade) movement of > > other packages through their version space. > > So, hypothetically, if you have the 05/08 "entire" incorporation installed, > when 11/08 openSolaris packages show up in the repository, they won't show > up in the potential upgrade list? They'll show up, just not as upgradable (though the way the code is right now, they would). > And you would need to explicitly install the new 11/08 "entire" > incorporation to upgrade to them? Yup. > So rather than hundreds of potential packages showing up in the upgrade > list, you will just see the one possible upgrade to "entire", and if you > don't install it only minor updates to the existing 05/08 packages would > be available. That's definitely the idea. Indeed packages which are constrained by an incorporation wouldn't normally show up in pkg list at all, unless specifically requested (and then they'd be marked "incorporated"). > > The dependencies are optional -- that is, installing the incorporation > > doesn't install the packages mentioned in the dependencies. > > So in a future openSolaris installer, the "entire" package would be > installed to define the revision level of the release, as well as whichever > specific clusters or packages you picked? I wouldn't count on the name staying the same, but that's the idea. I doubt we'd have an incorporation for truly everything that was installed, but there would be one which incorporated the bits we now call "the WOS". > "slim_install" does seem to only contain dependencies, but "slim_cd" has no > dependencies listed, just a handful of files: Whoops, yes, you're right. > It looks like it is more relevant to the live CD distribution than the > operating system once it has been installed? I'm guessing the etc/passwd > and etc/shadow files included in the package define the "jack" user. Yup. Though I think that it being there is a bug. Some of the bits associated with it are still there (gdm configuration), but some of the bits aren't (jack user). > So from an abstract point of view, even though the dependencies are not > enforced, it seems it would be better to remove the slim_install package if > you're going to move any of the packages depended by it. Yes. Though it's not clear to me that slim_install should actually be installed on the system, either as a cluster or as an incorporation. > Thanks for the explanation, I'm sorry for the torrent of questions I've > been posting this week. I'm trying to wrap my head around this and see if > it will be workable for our production ZFS file server we're going to > deploy soon. No problem. It's always good to get constructive feedback! Thanks, Danek
