pactrans: support for inverting default options

[AladW]

Related to #4: If updating a single repository with pactrans --sysupgrade, and the repository contains a package which conflicts with a package in a different repository, pactrans asks to replace this package, assuming as default "Yes".

This is somewhat unexpected (at least for me) as keeping a conflicting package in a local repository does not automatically mean you'd want it as replacement. It matters little for interactive use, but --no-confirm selects this default.

pacman has an undocumented feature for this (see https://git.archlinux.org/pacman.git/commit/?id=90e3e026d1236ad89c142b427d7eeb842bbb7ff4), so pacman --ask 2 would invert the default. I wonder if something like this makes sense for pactrans, or if this is just an inherent limitation with updating a single repository needing a different approach.

[andrewgregory]

I'm not sure how this relates to #4. If --sysupgrade is pulling in a conflicting package, it would generally do so regardless of whether you're working with a single repository or all of them.

I'm not sure exactly what behavior you're describing. Despite the documentation to the contrary, --no-confirm actually only only affects the 'Proceed with...' prompt. Can you be more specific about exactly what you ran, what happened, and what you'd like to happen?

[AladW]

The issue seems to be because the package in question filled in the replaces field: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=avahi-gtk2#n16

When running pactrans --sysupgrade with the regular pacman.conf, no replacement occurs because the local repository (with avahi-gtk2) is placed below the repository containing the replacement candidate (avahi)

[archie@thinkpad ~]$ sudo pactrans --sysupgrade --no-confirm
aurutils-git: local (1.3.6.r78.g8606582-1) is newer than custom (1.3.6.r48.g1807750-1)
nothing to do

If a configuration is specified that only contains [custom], the following happens:

[archie@thinkpad ~]$ sudo pactrans --config=local.conf --sysupgrade --no-confirm
aurutils-git: local (1.3.6.r78.g8606582-1) is newer than custom (1.3.6.r48.g1807750-1)

:: Replace 'avahi' with 'avahi-gtk2'? [Y/n] 

The same effect can be achieved by moving [custom] above other repositories.

In any case you're right that --no-confirm does not affect this prompt, so I guess having an option to change the default response (Y to N) has little consequence then.

Is there a particular reason why --no-confirm only influences this prompt in particular?

[andrewgregory]

This looks like a case of bad packaging then, there's no reason for the package to use replaces. As for why --no-confirm behaves the way it does, at the moment it's just a quirk/oversight. I actually don't like --no-confirm though and think wrappers shouldn't just blindly assume a response to important questions. One of the main advantages of pactrans is that it can install and remove at the same time, so it's possible to explicitly remove conflicting/replaced packages and avoid the questions altogether. I might even make --no-confirm exit with an error on any questions from libalpm.

[AladW]

Ok, that sounds reasonable to me. Thanks for the input.

[AladW]

How about to more specifically make noconfirm only apply to the install or remove question, and otherwise exit with an exit code depending on the asked libalpm question?

[actionless]

also it would be nice to have some option to only skip :: Proceed with installation? [Y/n] question but show all the other questions normally with the interactive prompt