Thanks for the clarification Dan. So at present due to a series of bug fixes Update All is fine, but in future may not be.
This is a certainly a real problem. If we warn the users then what are we meant to tell them? And more importantly what are they meant to look for? Something along the lines of: "Update All will update all your packages but may require some manual steps, please refer to the release notes to see if this is the case for this Update." Really ugly from a users standpoint. Makes them worry are any other steps with a problem in the GUI, what should I trust, what should I not. It also forces them to trawl through all of the release notes to make sure nothing is there about Update All :( If you need to update IPS and IPS GUI before doing a particular release, this warning will also be of no use as you won't have the latest release notes. Would the correct place to solve this not be in image-update? If this is an incompatible update from what's on my system, it should fail and give back an error code the GUI can then surface to the user, pointing them at a suitable URL to pick up the manual instructions. If this image-update has a dependency on a newer version of IPS and/or IPS GUI, could an upgrade of these packages be triggered first, again notifying the user and indicating a restart of the IPS GUI would be required, before proceeding with the Update All. On balance for now it may just be best to leave the Update All in place as it will currently work, without warning the user. JR Dan Price wrote: > On Thu 31 Jul 2008 at 09:06AM, John Rice wrote: > >> I agree with the need to provide some warning for the pkg(1) >> image-update. >> >> However, I disagree with doing this in the GUI. The GUI is meant to >> make actions simple and obvious. If an action is not fully >> automated and requires some external steps to complete safely then >> we should remove the functionality until it can be carried out by >> the GUI without any other external steps. The GUI should expose the >> functionality when its ready. This is particularly true if at >> present an image-update can brick your system if you have not >> carried out some additional steps. >> > > John, > > I'm sure David will correct me if I'm wrong. My take is as follows. > > The lack of automation in this space has been an issue since day one of > 2008.05 and it's hardly a secret. Just review: > > http://opensolaris.org/os/project/indiana/resources/rn3/ > > And you can easily see that even if the "update all" button in the GUI > had been working for the past couple of months, the GUI would not really > be usable for a system wide update. > > Due to hard work by Ethan and others, as far as I understand, for the > BTS release (snv_86 + fixes), for the things we know about (grub, libbe, > etc), bricking (or other brokenness) won't be the case when users do > that very first update which takes them forward to (today) build 94. > But there is no guarantee that an update from the BTS release to some > future version won't demand some sort of user intervention. At least, > not until we've done real design in in the underlying mechanisms in this > area. > > As an example-- imagine an update to some future build (say b99) which > triggers a bug in the packaging system itself! In that case the user > will first need to update the packaging system (including perhaps the > GUI, if the bug shows up there too) before doing the rest of the update. > > That's what this section in the update instructions is about: > > $ pfexec pkg refresh > $ pfexec pkg install [EMAIL PROTECTED] > $ pfexec pkg install [EMAIL PROTECTED] > > I will advocate to the pkg(5) team that this is a problem we need > to get more religion about. We've got some folks who I think will > be interested to work on solving this. > > -dp > > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
