[pacman-dev] [PATCH v3] Treat packages to be printed as non-ignored

[Andrew Gregory]

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