[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.2-56-g143135e
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 143135e666f5564240868810f0b8f4bc46ff87b5 (commit) via ca1a187131d95604ff2c33df3c1ec80ef4af789b (commit) via 8cfccf68c1c7fdd45c172d49115e56e04dae2a2c (commit) from 3ad3077d8d5bb0d67652d0045e3e5eaf4eef6ffb (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 143135e666f5564240868810f0b8f4bc46ff87b5 Author: Chantry Xavier <shiningxc@gmail.com> Date: Tue Feb 19 00:44:09 2008 +0100 Improve yesno function. Add a preset paramater to yesno function saying which answer should be the default. Ref: http://www.archlinux.org/pipermail/pacman-dev/2007-June/008470.html This allows us to answer no by default to some questions, like the -Scc one mentioned in the above thread, and implemented by this patch. Another advantage is that we don't have to repeat the [Y/n] in every questions. It's only put once in yesno function. This highly reduces the chances that YES and NO strings are translated, but not some questions, which lead to obvious confusions. Finally, the noconfirm variable only needs to be used in that yesno function. So all other usages of it were removed. Signed-off-by: Chantry Xavier <shiningxc@gmail.com> commit ca1a187131d95604ff2c33df3c1ec80ef4af789b Author: Dan McGee <dan@archlinux.org> Date: Sun Feb 24 18:07:44 2008 -0600 More cleanup to alpm_list * Remove some #include statements that are not strictly necessary * Remove node_new function that is really just a one-liner Signed-off-by: Dan McGee <dan@archlinux.org> commit 8cfccf68c1c7fdd45c172d49115e56e04dae2a2c Author: Nagy Gabor <ngaba@bibl.u-szeged.hu> Date: Sat Feb 23 22:31:20 2008 +0100 alpm_list.c clean-up * Introduces 'list == NULL' convention for empty list. That means alpm_list_new isn't needed anymore, so kill it * Small straightforward fixes in alpm_list.c Signed-off-by: Nagy Gabor <ngaba@bibl.u-szeged.hu> Signed-off-by: Chantry Xavier <shiningxc@gmail.com> ----------------------------------------------------------------------- Summary of changes: lib/libalpm/alpm_list.c | 136 ++++++++++++++++++++++------------------------- lib/libalpm/alpm_list.h | 1 - src/pacman/callback.c | 34 ++++-------- src/pacman/remove.c | 6 +- src/pacman/sync.c | 30 ++++------- src/pacman/util.c | 32 ++++++++--- src/pacman/util.h | 2 +- 7 files changed, 113 insertions(+), 128 deletions(-) hooks/post-receive -- The official pacman repository
- Log ----------------------------------------------------------------- commit 143135e666f5564240868810f0b8f4bc46ff87b5 Author: Chantry Xavier <shiningxc@gmail.com> Date: Tue Feb 19 00:44:09 2008 +0100
Improve yesno function.
Add a preset paramater to yesno function saying which answer should be the default. Ref: http://www.archlinux.org/pipermail/pacman-dev/2007-June/008470.html
This allows us to answer no by default to some questions, like the -Scc one mentioned in the above thread, and implemented by this patch.
Another advantage is that we don't have to repeat the [Y/n] in every questions. It's only put once in yesno function. This highly reduces the chances that YES and NO strings are translated, but not some questions, which lead to obvious confusions.
Finally, the noconfirm variable only needs to be used in that yesno function. So all other usages of it were removed.
Signed-off-by: Chantry Xavier <shiningxc@gmail.com>
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. 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. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
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. Oh, I was wrong here...: a question with safer yes answer should have been here :-P
Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
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.
participants (3)
-
Dan McGee
-
Nagy Gabor
-
Xavier