Joanie et al,
I think a possible solution here is as follows:
When you do an Update All or Install of any package that will require a
reboot, we should automatically create a BE (equiv to CLI --if-needed
option). If a BE needs to be created the user is notified at the end of
the Update All or Install operation in a Update All/ Install Completion
Dialog. This dialog contains a text field with the New BE name, which
users can accept or modify if they wish.
To explain the New Boot Environment to the user we will have a 'What's
This?' link beside the New BE Name textfiled for users to get more
details on:
-- What the BE is?
-- Why it was created?
-- How they can use the new BE to see their Updates.
Now if the user carries out an Update, Install or Remove operation that
does not need a BE to be created it would be great to create a snapshot
for them automatically. We could have a Preference to prompt the user
for the snapshot name, but I think if its labeled with "<operation>
<package> <time>" that should probably be fine for most users. In the
History dialog below users could change snapshot names if this is
supported.
When we asked about this some months ago, there were reasons why this
was not currently doable due to mixing system and user based snapshots,
not sure if this is still the case.
Where this could be exposed would be in a History dialog that would list
the operations that had taken place (using an extended History API that
both GUI and CLI could take advantage of). Using a simple Time Slider
style interface int eh GUI we could allow them to move back and
forwards, between snapshots and or BE's, with appropriate warnings to
the user if they are going to change to a new BE and so on.
Update All (BE opensolaris-11-10-2009)
- Install foobar
- Removed zeebar
Install woobar (BE opensolaris-11-08-2009)
- Install moobar
:
Update All (BE opensolaris-07-10-2009)
:
JR
Joanmarie Diggs wrote:
On Fri, 2009-10-23 at 13:36 -0400, Dave Miner wrote:
[...]
A couple of reasons why I prefer the BE:
- It's directly surfaced into the boot loader as something bootable,
should you need to get back to it. A mere snapshot requires additional
action to actually be bootable, and if you're in a failure state, that
can become problematic.
- The snapshots aren't as visible in either beadm or zfs without adding
options, which seems to make space management more involved.
Beyond that, it seems to me that your "no danger of rendering the
current boot environment unbootable" criterion would be difficult to
apply automatically; the dependencies involved in getting to even
single-user are somewhat far-reaching and dynamic. I've found lots of
ways to get there when doing the live CD work ;-)
I love OpenSolaris, among other reasons, because of its reliability. So
I wouldn't want that reliability to be jeopardized in any fashion. I
also am jumping in on a discussion the implications of which I
admittedly do not fully comprehend. So.... Functionally speaking:
If a package can be updated by performing an image-update OR
alternatively by doing an install of that package, I do not want a new
boot environment. If updating the package in question has the potential
to render my current BE unbootable, then shouldn't I be prevented from
updating it via install so that I don't find myself in the failure state
you describe? :-)
Under the above circumstances, what I do currently is to first take a
snapshot with a meaningful, grepable name. Then I manually install the
package -- or packages -- in question. What I would really like to do in
this case is an image-update. I would be prompted for a *snapshot* name
rather than a BE name (in the case of the GUI, anyway), and the packages
would be updated. Same number of steps as the current image-update (and
fewer steps than what I must currently do), a fallback plan in the form
of a snapshot which is visible in both beadm and zfs, and no new BE.
Doesn't have to be the default option, but if it could be *an* option,
that would be awesome.
Take care.
--joanie
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
