On 03/15/13 at 08:21pm, Connor Behan wrote:
On 15/03/13 04:49 PM, Andrew Gregory wrote:
On 14/03/13 03:25 PM, Andrew Gregory wrote:
On 03/14/13 at 12:40pm, Connor Behan wrote:
I could modify the patch so that it limits ignorepkg to packages beside --ignore rather than clearing it. I could also check the command line arguments so that if any of them are groups rather than packages, we just bail and forget about changing ignorepkg. This would make the patch less trivial but it would change as little of the API as possible.
Now that Xyne has mentioned it, I actually like the current behaviour of not printing ignored URLs for group operations. If this has been a bug all along and the automation tools will have to be changed anyway then we are once again back to an easy patch.
Putting the issue of how much --ignore should do, I think the root issue is that pacman uses different default responses for --noconfirm and --print. --print uses alpm's default value, whereas --noconfirm uses a pacman-specific value. So "-S --noconfirm bar" would install foo but "-Sp bar" does not print foo. This is the same reason "-Sp foo" does not print foo. I see no reason why pacman shouldn't be using the same value for both, which, if I'm not mistaken, would fix your issue with devtools.
apg
So if I read correctly, explicitly installing an ignored package or installing a group that contains an ignored package asks a yesno question. The question callback says to return without an answer if config->print is true. Yes, pacman's entire callback function is skipped entirely if --print is used, which is why pacman returns no response at all to alpm rather
On 03/14/13 at 06:32pm, Connor Behan wrote: than the default response. Used with --noconfirm, pacman returns the default response.
If we want to keep this behaviour (and not have the user prompted for pacman -Sp), we would just make libalpm default to install=1 like pacman would do being sure to set it back to 0 if prompt=0. This option seems like the best in terms of logic. We would treat --noconfirm and --print symmetrically and there wouldn't be spaghetti code checking for some esoteric use case. However it would introduce the same complication for scripts that Xyne was worried about.
I don't think changing alpm's defaults is the correct solution here. I still see this as a purely frontend issue. The --print option already implies --noconfirm so the only reason I see for it to skip the callback altogether is to avoid printing the question. I think the proper solution is to find another way to suppress that output that allows pacman to return the default response to alpm.
apg
Ok, so we fix it by making --print automatically imply --noconfirm? And not having the question callback check especially for --print?
--print already implies --noconfirm, no need to do anything there. You'll still have to check for --print somewhere in the callback process to avoid showing the questions. It just needs to be more selective so that only the output is skipped, not the entire callback function. apg