* Danek Duvall ([email protected]) wrote: > Glenn Lagasse wrote: > > > That seems pretty unuseful and not very user friendly to have to know > > before hand whether or not one needs the --be-name option for pkg > > install. Are there any plans to make this more usable to an end-user so > > that they don't have to be the equivalent of a mind-reader? > > Well, you never actually need it -- they're automatically named if > necessary, even if the names aren't always terribly descriptive. And if a > BE was created unexpectedly, you can always rename it after the fact. If > you don't want to do any of that, you can supply --deny-new-be and simply > have the command fail if a BE were to be created.
True, if I know about --deny-new-be and the semantics of doing a pkg install with or without it. Newbie's won't, I don't think. A user can of course rename a BE if one is created 'after the fact' but it would be good to inform the user before it's created I think. Least surprise and all that. If I'm not aware of this particular semantic with regards to installing a package that a new BE could be created I have no chance to rectify that without going through with it. True, a BE is created and I'll notice that once it's done and could decide after what I want to do. But I think I'd rather know before the deed is done and make an informed choice. 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. 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? > Did you have anything in mind? Given Shawn's statement that pkg is by design non-interactive I'm not sure what could be done here. My first thought was that if a new BE was going to be created (in the absence of any --deny-new-be or --require-new-be argument) that pkg would tell the user that it was going to create one (and why) and give them a chance to abort or continue (perhaps with a chance to name the resultant new BE) as they wish. 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. Then there's no surprise to the user. They run an install command, find out that a new BE would be required (which may have an impact on their decision to continue with the install or not) and can then make an informed decision about what to do. If they really want to install the package(s) that require a new BE they can call the command again (perhaps with the --require-new-be argument and even the --be-name argument). Maybe I'm over-thinking this, but I can easily see people having all kinds of BEs laying around with odd names with no idea how or why they got there because they installed some package(s) that required a new BE. And for people that don't want BEs generated willy-nilly, it could be an irritant for them as well. I should think that there won't be too many packages (overall) that need a new BE in order to install. Explicitly calling out those operations (by not allowing them to happen by default) seems like a good idea to me and something that unfamiliar users might appreciate. -- Glenn _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
