Arch Linux

SpaceshipOperations

Member

Registered: 2019-06-24

Posts: 15

More fine-tuned/selective `pacman --noconfirm` option

Yesterday I attempted to upgrade an ArchLinux installation that's been left unused for a very long time. Because it was asking for confirmation to replace old packages with new ones waaaaaay too many times, I decided to use the `--noconfirm` option (which I almost never use).

Unfortunately using it had a terrible unwanted effect: The pacman keyring was out of date, so after all downloads were finished, when pacman tried to verify the packages, it complained that they are "corrupted", asked for confirmation to delete them, and since `--noconfirm` was used, it answered yes to all these queries and automatically purged some 380 freshly downloaded packages.

Now before I proceed I want to say that I already solved the issue (it's pretty simple - just ran `pacman-key --refresh-keys`, then manually upgraded the `archlinux-keyring` package alone, then performed `pacman -Su`, of course without `--noconfirm` to make sure nothing gets purged without question again, and all packages were upgraded successfully). However, I still decided to make this post to bring up this problematic corner case.

I know that "no confirm" means "no confirm", so you could argue that this was a user error rather than a program error. But I don't think anybody on earth uses the option intending it to happily purge perfectly fine packages it just downloaded without confirmation. Ideally, when `--noconfirm` is used and the keyring is outdated, pacman should regress elegantly by simply exiting without deleting anything, to give the user a chance to refresh the keyring and try again without losing a mountain of freshly download packages that probably have nothing wrong with them.

If we want to treat this as a special case, it can be alleviated by as little as making 'no' the default choice for package (cache) deletion-related questions, at least when `--noconfirm` is used. (The same might be applied to any other questions where the 'yes' option is deemed to be mostly probably unwanted destruction, although I can't think of any such cases other than cache purging. e.g. Removing old packages to replace them with new/renamed ones is often the preferred option for the majority of people, the majority of the time, and those who want otherwise are typically the exception rather than the general case.)

However, I think it's also desirable to have a more selective version of `--noconfirm`, as it provides the user a powerful combination of convenience and control/sanity. For example, I typically want pacman to automatically say 'yes' to routine questions like 'Do you want to proceed with the upgrade?' and questions about replacing old packages with new/renamed ones, but I want to vet more important questions like choosing between two providers of the same feature, and of course I would never want it to delete entirely good packages it just downloaded just because the keyring is missing some updated keys that are necessary to verify them.

Having a selective `--noconfirm` gives the user the ability to have convenience most often, while still being able to control the important choices. If selective confirmation skipping is implemented, it could also be made into a `pacman.conf` option, so that users who want do not have to type the same combination of options/values on the command line over and over every time.

apg

Developer

Registered: 2012-11-10

Posts: 211

Re: More fine-tuned/selective `pacman --noconfirm` option

I doubt that's going to find it's way into pacman, but pacinstall can do it: https://github.com/andrewgregory/pacuti … on-options

SpaceshipOperations

Member

Registered: 2019-06-24

Posts: 15

Re: More fine-tuned/selective `pacman --noconfirm` option

Edit: Sorry, removing my reply because it contained erroneous info.

Last edited by SpaceshipOperations (2023-03-23 19:49:07)

SpaceshipOperations

Member

Registered: 2019-06-24

Posts: 15

Re: More fine-tuned/selective `pacman --noconfirm` option

I doubt that's going to find it's way into pacman, but pacinstall can do it: https://github.com/andrewgregory/pacuti … on-options

Forgot to reply to this but thanks for mentioning pacinstall.

Last edited by SpaceshipOperations (2023-03-23 19:48:21)

schard

Forum Moderator

From: Hannover

Registered: 2016-05-06

Posts: 1,975

Website

Re: More fine-tuned/selective `pacman --noconfirm` option

FWIW, I also hit this issue on a regular basis when updating our...

$ hwutil ls sys -o "Arch Linux" | wc -l
1823

Arch Linux systems.
Especially when they were offline for a prolonged time due to internet problems of our customers.
Anyway, I solved the issue similarly to your approach by running

# pacman -Sy archlinux-keyring

before running the system update.
But thanks to the new archlinux-keyring-wkd-sync.{timer,service} this issue is currently vanishing.
Hence I do not think that a further extension of the pacman CLI switches is warranted through this use case.

---

macro_rules! yolo { { $($tokens:tt)* } => { unsafe { $($tokens)* } }; }