Forgot to mention that the progress bar is for the entire download, not
per package.
Frank Ludolph wrote:
>From the UI point-of-view I have to agree with John and Dave:
- Don't warn the user unnecessarily as the user will soon ignore
it. Don't cry "wolf".
- Pair IPS and Pkg Mgr so that they stay in sync (as mentioned in
today's Indiana Distro meeting)
- Implement a "stay alive" mechanism. When either the IPS client
or
Pkg Mgr contact a repository and significant updates exist for them,
update them first if at all possible, or else error out with a note and
a URL specific to the Pkg Mgr/IPS client version.
Frank
John Rice wrote:
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
