Summary: | --ask --autounmask shouldn't exit on solvable conflict | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Keshav Kini <keshav.kini> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | esigra, njsg, pacho, SebastianLuther |
Priority: | Normal | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 376695, 484436 |
Description
Keshav Kini
2013-08-18 22:17:02 UTC
[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 released in portage-2.2.14_rc1 |