Glenn Lagasse wrote:
> But I think I'd rather know before the deed is done and make an informed
> choice.
What are your choices, if you knew that a BE was going to be created? You
could decide not to do anything at all, or you could choose an explicit
name. Is there anything else? Neither of these are fixed in stone and can
be undone quickly and reasonably after the fact (beadm destroy, beadm
rename).
Perhaps the GUI would be a place to make sure that you get a popup
requiring confirmation (configurably) and asking for a new name? I think
they may already ask you.
> Rather than find out after the fact, and then figure out how to put
> things back if I really didn't want to install the package(s) if they
> require a new BE.
How often would you want to install a package, but then decide that you
won't because you'd have to reboot to take advantage of it? It's not like
this is going to happen when you install openoffice -- this'll happen when
you've got kernel modules.
With the default output, you're told that a new BE is required as soon as
the packaging system knows. You can terminate the command at that point,
possibly having downloaded a few files, but likely well before the new BE
is created or activated. So if you really care, you do have an out, if
you're paying attention.
> I presume that any package(s) installed that require a new BE won't
> actually be usable until you're rebooted into that new BE. Is the user
> explicitly informed of this once the install completes?
The message emitted at the end of an image-update (and, I would expect, an
install that creates a new BE, assuming it activates it afterwards)
currently reads:
A clone of <current BE> exists and has been updated and activated.
On the next boot the Boot Environment <new BE> will be mounted on '/'.
Reboot when ready to switch to this updated BE.
It probably could stand to be reworded so that it's more clear that you
have to reboot to take advantage of the bits you just installed or
upgraded.
> If pkg must stay non-interactive, what about the default for pkg install
> being 'deny-new-be' and require some sort of flag to proceed if a new BE
> is required.
That's basically what we had before, and people were complaining about
that, too. If I ask for a package to be installed, then the packaging
system should make sure that it gets installed, and gets installed safely.
Erroring out and saying that you have to create a new BE, mount it, install
the package there with special flags, unmount, activate, and reboot, is
also a surprise to the user, and clearly a big pain, especially considering
that it's something we can do for them.
> Maybe I'm over-thinking this,
I think so. I'd like to see actual people having actual problems stemming
from this particular design choice (and not just some silly bugs) before we
redesign the user experience again. We can construct all sorts of
hypothetical users and hypothetical tasks for them, but it's difficult to
assign validity to any given scenario until we see what people are actually
doing and the problems they're actually running into.
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
