On 03/14/13 at 06:32pm, Connor Behan 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 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