[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.2-56-g143135e

[Xavier]

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.