* Danek Duvall ([email protected]) wrote: > 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.
I've thought about this some more after having read your response and I agree that it would be good to get more real-world feedback on this before coming to any conclusions. Thanks Danek, et-al. -- Glenn _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
