fix: Pacman provider uses unrecognized option '--update'

[fmichea]

Short description

In cf789b7, long command parameters were introduced for readability. Command argument -U was changed to --update but as can be seen in the previous commit's description and below, the actual replacement for this shorthand is --upgrade. With this commit, the correct long form is added.

Examples from command line:

[root@host ~]# pacman --update
pacman: unrecognized option '--update'
[root@host ~]# pacman -Uh
usage:  pacman {-U --upgrade} [options] <file(s)>
options:
   ...

Checklist

I have:

• read the CONTRIBUTING.md document
• read and accepted the Developer Certificate of Origin document and added a Signed-off-by annotation to each of my commits
• read and accepted the AI Policy document and added Generated-by or Assisted-by annotations to each of my commits created with the help of an AI agent
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• added or modified unit test(s)

[Sharpie]

Looks good, matches pacman --help output. Thanks for the fix!

[Sharpie]

@fmichea tests passed, but this commit will need to be signed with a SSH or GPG key in order for the pull request to be mergable.

[fmichea]

@Sharpie I should have commented, I don't know if this change should really be merged in. It does fix the issue of the command line argument, however having tried to get it to trigger in my manifests after submitting this PR, I must say that I was unsuccessful.

Going from memory so pardon inaccuracies: First it does not look like it is possible to specify only source parameter, version is always required, but because this package provider does not support :versionable it is not possible to use version => "v1.2.3". I believe neither present or latest (with a source) enforced the specific version of the package provided either. The code would execute, but it would not upgrade/downgrade a package if already installed or on the latest version.

Worth noting also, pacman does not seem to support version pinning itself, there is an IgnorePkg configuration option available but no way to specify a version in particular that the package manager should track. This provider does not set this config option so any use of pacman outside the manifests might set the package to a different version than the one specified in the manifests.

As is, I would say this path in the provider is not functional, it's a little more correct with this change, but I wouldn't say this code works. It at least requires a lot more testing to understand how to use. I ended up writing a shell script executed on manifests run to force install the right version and maintaining IgnorePkg separately in my own manifests to get around these issues.

What do you think should happen? In my own projects without finding a way to call it properly, I think I would personally lean to remove the code path entirely, however this is a public repo and the previous versions with shorthands might have allowed people to use it successfully in their manifests so probably not an option for you.

[Sharpie]

@bastelfreak as an Arch Linux user, do you have any thoughts on this one?