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

[Connor Behan]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/pacman-dev/attachments/20130315/db1408ed/attachment.asc>