From #gentoo-portage on freenode: [2013-08-18 17:00:58] <kini> when portage finds a conflict and tells the user to rerun with --autounmask-write , why not just prompt the user to do it immediately? [2013-08-18 17:01:07] <kini> that way portage doesn't need to rerun the dependency graph calculations [2013-08-18 17:05:05] <zmedico> kini: we could do that with --ask. file a bug if you like
[2013-08-18 19:58:56] <dwfreed> kini: that should be "--ask --autounmask"
I don't understand what you want. It sounds like you want --ask --automask to be the same as --ask --autounmask-write, but then you could just... do --ask --autounmask-write.
Yes, I could just always run emerge with --autounmask-write, but a user typically wouldn't run --autounmask-write unless they had reason to believe it was necessary, and they wouldn't have reason to believe it was necessary unless they had been told so by --autounmask, *which is on by default*. Now, I'm *not* asking --autounmask-write to be on by default, of course. I suppose I am asking for --ask to imply --autounmask-write. The point is, from a user's perspective, considering they've specifically asked `emerge` to be interactive with --ask, it is ridiculous to see `emerge` telling them "I've done a bunch of analysis and figured out that I could fix things by doing X, but I won't do X because you didn't provide the right command line flag. Next time provide the command line flag, and I'll do X after doing the exact same analysis all over again." Incidentally, on my system, walking the dependency graph takes a good five minutes sometimes, so it's not just a trivial annoyance either.
(In reply to Keshav Kini from comment #3) > Yes, I could just always run emerge with --autounmask-write, but a user > typically wouldn't run --autounmask-write unless they had reason to believe > it was necessary, and they wouldn't have reason to believe it was necessary > unless they had been told so by --autounmask, *which is on by default*. Now, > I'm *not* asking --autounmask-write to be on by default, of course. I > suppose I am asking for --ask to imply --autounmask-write. I have a patch that does this, but I'm not sure I agree with it from a design POV. I sometimes want to run it with --ask and not have that imply --autounmask-write. I honestly see no point in --autounmask and want to get rid of that and then rename --autounmask-write to --autounmask. This should be off by default, and when invoked with --ask should do what --ask --autounmask-write does presently. I'll wait for Zac to reply with his thoughts (obviously, I encourage you as a user to share your thoughts as well) -- if he agrees with my reasoning, I will write a patch that does this instead. If not, and he agrees with your initial point, I will upload the patch I have that does what you request.
Additional comment: I would also want to make --autounmask-write on by default when emerge is run with --ask, as this is what makes sense for me and the way I use emerge.
If the only thing --autounmask does is a --pretend version of --autounmask-write, I don't really see why should we have both instead of relying on --pretend and --ask. Those already exist, and in fact a similar thing is done when fetching packages (emerge -pf vs. emerge -f). +1 for the rename
rename++. This would be better behaviour.
Sounds good to me, fwiw.
(In reply to Alexander Berntsen from comment #5) > Additional comment: I would also want to make --autounmask-write on by > default when emerge is run with --ask, as this is what makes sense for me > and the way I use emerge. Sounds good to me. So, --ask + --autounmask implies --autounmask-write.
(In reply to Zac Medico from comment #9) > Sounds good to me. So, --ask + --autounmask implies --autounmask-write. This is not what I am suggesting entirely. I would remove --autounmask-write and turn --autounmask into --autounmask-write and change the defaults. My suggestion would be like this: emerge --ask --autounmask foo would do what currently is done by: emerge --ask --autounmask-write foo emerge --ask foo would also do what is currently done by: emerge --ask --autounmask-write foo emerge --autounmask foo would do what is currently done by: emerge --autounmask-write foo emerge --pretend --autounmask foo would do what is currently done by emerge --autounmask foo So I would remove the current --autounmask entirely and rename the current --autounmask-write into --autounmask, and do (pseudo code) autounmask = get_option('--autounmask') or ask so that if the user has specified --autounmask it will get naturally get autounmask, but if the user has ask it will get ask (of course) and autounmask like --ask --autounmask-write does today. I hope this is somewhat clear... If not, you'll see what I mean when I write the patch tomorrow. ;-)
Can't we just enable the current --autounmask-write option by default, and allow the user to use --autounmask-write=n if they don't like the new default for some reason?
(In reply to Zac Medico from comment #11) > Can't we just enable the current --autounmask-write option by default, and > allow the user to use --autounmask-write=n if they don't like the new > default for some reason? Yes, but I don't think that's a good idea. --autounmask is quite useless as is, and with your proposed change --autounmask becomes *really* useless. Furthermore, not checking for that useless option is one more step at a more manageable source code. What is even more, --autounmask-write should not be default when --ask is not used. I believe quite firmly that my proposed solution is better, as a Portage hacker and user both. I also get the impression that the users here agree with me. If you still disagree I will implement it the way you suggest, as I have no desire to tread water.
(In reply to Zac Medico from comment #11) > Can't we just enable the current --autounmask-write option by default, and > allow the user to use --autounmask-write=n if they don't like the new > default for some reason? Since autounmask still has many issues including nonsensical suggestions I'd say it's not a good idea and people should always review those suggestions. --autounmask-write=y is generally not recommended in #gentoo, because it makes users lazy and get weird results, although we have CONFIG_PROTECT
The --autounmask option exists because in the days when this feature was introduced first, it could produce strange results and some people wanted a way to get the old behavior (i.e. fail on the first problem) back. I don't know if there's anyone using --autounmask=n these days. I wouldn't care if it is removed. If you really want to rename --autounmask-write into --autounmask, write a news item. Otherwise people with --autounmask in their EMERGE_DEFAULT_OPTS will get quite unexpected results. I'm against enabling --autounmask-write by default for the reasons mentioned in comment 13.
(In reply to Sebastian Luther (few) from comment #14) > If you really want to rename --autounmask-write into --autounmask, write a > news item. Otherwise people with --autounmask in their EMERGE_DEFAULT_OPTS > will get quite unexpected results. I agree > I'm against enabling --autounmask-write by default for the reasons mentioned > in comment 13. I agree.
This is in git: https://github.com/gentoo/portage/commit/3bdaadba9d326374c978c4a521a9db4125279430
This is released in portage-2.2.14_rc1
