On Mon, Feb 25, 2008 at 01:29:14PM +0100, Nagy Gabor wrote:
Basically I like this change. 1. However, I don't see why -Scc needs different treatment from others: why is -Scc more dangerous than "remove whole content?"? <- -Scc needs explicit parameters in command-line, while '-R group' is kind an implicit stuff imho.
See the reference to pacman-dev ML archives in git commit log. Romashka said it could be easy to mistype -Scc instead of -Sc. I agree that the different questions asked in each case should already solve that problem though. I guess I just needed a question where I could change default answer value :) In any cases, it's not a big deal.
2. The last "fallback" 'return(0)' of yesno is also confusing: If I accidentally type 't' instead of 'y' then -Scc still will clean-up the whole cache. 3. To be honest I don't know whether return(preset) or return(!preset) is better, because I couldn't figure out the current principle of this default/fallback/noconfirm yesno stuff. My suggestion: If I define --noconfirm as "pacman presses Enter ;-)", then default return == noconfirm return (this is done). And in my opinion fallback return should indicate an error (-1) or question-repeat, because pacman shouldn't decide instead of me in case of typo.
Well, I had a problem here indeed. But I thought this was the easiest way. Then Dan also asked me about it before merging it, but let it that way because it's acceptable and can easily be changed later. If you look at how the current yesno function is used, its always : if(yesno(...)) /* user answered yes */ else /* user answered no */ And this is quite natural in my opinion. If yesno now returned -1 in case of errors, and by mistake or overlook, you still used yesno like before, then an error returned be yesno() would be taken like a yes.. (if(-1) : true). And if we assume that yesno function will be used correctly, it also adds more complexity (additional return value to check + error handling to add everywhere). Finally, it's already the way it worked before. It returned yes if you typed y or yes, and no in every other cases. yesno could never fail, and that worked fine. However, I agree that no is not necessarily the safest answer. Actually, it could even be dangerous. And the fact that we can now change the default answer makes this even more complicated. I didn't even think about the question-repeat idea. It might be the best solution after all.