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

Andrew Gregory andrew.gregory.8 at gmail.com
Sat Mar 16 09:58:27 EDT 2013


On 03/15/13 at 08:21pm, Connor Behan wrote:
> On 15/03/13 04:49 PM, Andrew Gregory wrote:
> > 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
> >
> 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


More information about the pacman-dev mailing list