Alexander Berntsen posted on Wed, 13 Aug 2014 18:56:28 +0200 as excerpted: > One thing that needs discussion is what to do with the current behaviour > of --autounmask, i.e. printing the suggestions. One thing that was > really weird in my original patches (the ones in this thread) > is this: > > emerge foo # this will do what --autounmask does today > emerge foo --autounmask # this will do what --autounmask-write does > emerge foo -a # this will do what --ask --autounmask-write does > emerge foo --autounmask=n # this will do what --autounmask=n does > > The problem here is that there is no way to do e.g. emerge foo --ask, > and get suggestions any longer. You can either have it prompt to write > stuff, or you can have it not do anything -- but you can't explicitly > have it suggest stuff without prompting to write. This is bad design. > > So either I need to implement tri-state (--autounmask can be yes, no, > suggest), or I need to do something more drastic.
This remains my problem with the patches as they are now. * I don't want portage writing mask/use changes on its own under any circumstances, as I use directories and have my own idea of what files I want stuff in. * Never-the-less, I find the suggestions very helpful and indeed, often the easiest way to find out what I need to do. * I routinely use --ask. Currently, --ask assumes "yes" very easily, simply hit return, and I like that behavior for simple merges as it's convenient and easily enough undone. (With --oneshot by default as well, an errant enter is undone easily enough with a --depclean.) The patches as they are now would change that, giving me no way to still get the suggestions with --ask, without chancing the actual write of those changes. That's particularly bad as the currently convenient behavior of letting a simple enter indicate yes makes it all too easy to actually do those writes I don't want done under any circumstances. While I'm fine with --ask defaulting to (the current) --autounmask-write behavior by default, I need a way to get the current --ask --autounmask (without write) behavior too, even if I need to add --autounmask=suggest or some such to DEFAULTOPTS, because that's /my/ configuration's default behavior, and I want it to stay that way. =:^) So please do implement that tri-state --autounmask=suggest behavior. =:^) The only other /possible/ objection I see is the potential version- dependent confusion over --autounmask behavior. An argument could be made that it might be better to simply kill the --autounmask switch, hard- wiring that behavior, and keep the current --autounmask-write name, simply making it the default while still allowing people to explicitly set --autounmask-write=n. That way, while the remaining --autounmask-write parameter would arguably unnecessarily keep it's longer name, there could be no confusion over the changing --autounmask behavior, since that parameter would simply cease to exist. But I don't feel strongly about that. If people think the confusion over --autounmask changing meaning isn't as big a deal as saving those few extra characters necessary for the longer -write variant, fine with me. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
