[pacman-dev] [PATCH] Add new -Sq / --needed option.
This patch is the result of the constatation than, during one pacman
operation, the "local version is up to date. Upgrade anyway?" questions are
usually all answered either by yes or by no.
Yes when you want to reinstall all the targets.
No when you only want to install the missing ones (either because you are
installing a group, or because you are copying a pacman -S line from wiki or
whatever).
So instead of asking this question for every targets, it'll now be
configured with a flag.
Yes will be the default -S behavior, No will be achieved with the --needed
flag.
Signed-off-by: Chantry Xavier
This patch is the result of the constatation than, during one pacman operation, the "local version is up to date. Upgrade anyway?" questions are usually all answered either by yes or by no.
Yes when you want to reinstall all the targets. No when you only want to install the missing ones (either because you are installing a group, or because you are copying a pacman -S line from wiki or whatever).
So instead of asking this question for every targets, it'll now be configured with a flag. Yes will be the default -S behavior, No will be achieved with the --needed flag.
Signed-off-by: Chantry Xavier
Wow, you are really active now. Great, I like this feature. Now I will be an asshole (please don't kill me;-): 1. Personally I would have kept the current behaviour (ask for user, he may answer mixed answers), and add an option for both "answer-yes" and "answer-no". Because usually when I get this question (copy-paste from wiki ;-), my reaction is ctrl-c (<=> I want to do answer-no)... 2. This will be a contra for my -Ru patch too: This should be handled in front-end's callback.c imho (to keep libalpm as flexible as possible), and that should answer the question automatically. This is similar to ask, but new command-line options for each question-type is much clearer imho. 3. I go further: Even remove_cascade and remove_unneeded should be done in front-end. This could be an "interactive" remove-dependency-error resolving: "Removal of foo would break the bar dependency of baz." "Do you want to keep foo?" [REMOVE_UNNEDED answers yes, default answer no], if the answer was no: "Do you want to also remove baz?" [REMOVE_CASCADE answers yes, default: no]... if the answer was no: depcheck error What's more, this can be handy in case of resolvedeps, this would help pacman (== user) choose a proper satisfier. "To-be-installed foo has an unsatisfied dependency bar. Baz satisfies bar. Do you want to install baz?" [default answer: yes; optional: no <- no dependency resolve, BUT exit with error; optional: prompt to user <- user can find his favourite dependency].... Well, this mail may be a bit chaotic (random new ideas in my mind), sry. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Sat, Nov 24, 2007 at 02:55:24PM +0100, Nagy Gabor wrote:
Wow, you are really active now. Great, I like this feature.
Now I will be an asshole (please don't kill me;-): 1. Personally I would have kept the current behaviour (ask for user, he may answer mixed answers), and add an option for both "answer-yes" and "answer-no". Because usually when I get this question (copy-paste from wiki ;-), my reaction is ctrl-c (<=> I want to do answer-no)... 2. This will be a contra for my -Ru patch too: This should be handled in front-end's callback.c imho (to keep libalpm as flexible as possible), and that should answer the question automatically. This is similar to ask, but new command-line options for each question-type is much clearer imho. 3. I go further: Even remove_cascade and remove_unneeded should be done in front-end. This could be an "interactive" remove-dependency-error resolving: "Removal of foo would break the bar dependency of baz." "Do you want to keep foo?" [REMOVE_UNNEDED answers yes, default answer no], if the answer was no: "Do you want to also remove baz?" [REMOVE_CASCADE answers yes, default: no]... if the answer was no: depcheck error What's more, this can be handy in case of resolvedeps, this would help pacman (== user) choose a proper satisfier. "To-be-installed foo has an unsatisfied dependency bar. Baz satisfies bar. Do you want to install baz?" [default answer: yes; optional: no <- no dependency resolve, BUT exit with error; optional: prompt to user <- user can find his favourite dependency]....
Well, this mail may be a bit chaotic (random new ideas in my mind), sry.
Handling this in callback.c might be a good idea, I don't know. If you believe it is, please provide a patch, it'll be easier to judge it :)
Hmm, Dan merged the 'quiet' patch already, which means -q is now taken 8) Maybe we only want a long option here?
On Mon, Nov 26, 2007 at 12:30:18PM -0600, Aaron Griffin wrote:
Hmm, Dan merged the 'quiet' patch already, which means -q is now taken 8)
Maybe we only want a long option here?
Yes, that's what I chose when rebasing my patch, so it's already done :) I felt it was not necessary to resubmit the patch on the ML since it's a minor change. I just updated it in my git repo, and it's available there.
On Nov 26, 2007 12:33 PM, Xavier
On Mon, Nov 26, 2007 at 12:30:18PM -0600, Aaron Griffin wrote:
Hmm, Dan merged the 'quiet' patch already, which means -q is now taken 8)
Maybe we only want a long option here?
Yes, that's what I chose when rebasing my patch, so it's already done :) I felt it was not necessary to resubmit the patch on the ML since it's a minor change. I just updated it in my git repo, and it's available there.
Yeah, I didn't check yet - not at home, so no gitk 8)
participants (4)
-
Aaron Griffin
-
Chantry Xavier
-
Nagy Gabor
-
Xavier