On 14/03/13 03:25 PM, Andrew Gregory wrote: > On 03/14/13 at 12:40pm, Connor Behan wrote: >> On Thu, Mar 14, 2013 at 10:02 AM, Andrew Gregory <[email protected] >>> wrote: >>> On 03/15/13 at 02:40am, Allan McRae wrote: >>>> On 15/03/13 00:30, Dave Reisner wrote: >>>>> On Wed, Mar 13, 2013 at 11:37:10PM -0700, Connor Behan wrote: >>>>>> Calling pacman -Sp and pacman -Sup are guaranteed not to install a >>>>>> package. >>>>> I feel the need to point out that --ignore guarantees that a package >>>>> won't even be *downloaded*. Xyne already mentioned it, but I'll parrot >>>>> his concern about this effectively changing command line API. >>>>> >>>> Where do you get that guarantee? All the documentation says is: >>>> >>>> Instructs pacman to ignore any upgrades for this package when performing >>>> a --sysupgrade. >>>> >>>> So I am not even sure Xyne's example is valid, based purely on what this >>>> is documented to do... -Sp is not an --sysupgrade operation, and this >>>> patch specifically keeps --ignore for -Sup operations. >>>> >>>> >>>> So... to understand what people think pacman _should_ do, if "foo" (in >>>> group "bar") is in IgnorePkg: >>>> >>>> "-Sup" should not print a URL for foo (not up for debate...) >>>> >>>> "-Sp foo" should print a URL for foo (currently does not). >>>> >>>> What should "-Sp bar" print? From what is currently documented, it is >>>> not a --sysupgrade, so IgnorePkg should not have an effect. From what >>>> currently happens, it should not print a "foo" URL. >>>> >>>> Allan >>>> >>> "-Sp bar" should print a URL for foo. >>> >>> A sysupgrade is very different from syncing or removing a group, so >>> IgnorePkg should only ignore upgrades not remove the package from >>> group operations. The fact that IgnorePkg is applied to any >>> operations other than sysupgrade is a bug. In fact, --ignore and >>> IgnorePkg have no effect on removal which creates an odd disparity >>> between syncing and removing groups. >>> >>> apg >>> >>> >> 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.
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.
signature.asc
Description: OpenPGP digital signature
