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?

[bastelfreak]

@fmichea indeed --update is wrong and this should be --upgrade:

$ pacman -U --help
usage:  pacman {-U --upgrade} [options] <file(s)>

---

Since the pacman provider isn't versionable as you pointed out, you cannot install a specific version of a package if another version is already installed.

it fails to install 3.5.0 when 3.5.1 is installed:

root@bastelfreak-nb ~ # puppet resource package htop ensure=installed source=/var/cache/pacman/pkg/htop-3.5.0-1-x86_64.pkg.tar.zst
package { 'htop':
  ensure   => '3.5.1-1',
  provider => 'pacman',
}
root@bastelfreak-nb ~ # pacman -Q htop
htop 3.5.1-1
root@bastelfreak-nb ~ #

but when htop is absent:

root@bastelfreak-nb ~ # pacman -Q htop
htop 3.5.1-1
root@bastelfreak-nb ~ # pacman --noconfirm -Rns htop
checking dependencies...

Package (1)  Old Version  Net Change

htop         3.5.1-1       -0.39 MiB

Total Removed Size:  0.39 MiB

:: Do you want to remove these packages? [Y/n]
:: Processing package changes...
(1/1) removing htop                                                                                                             [#############################################################################] 100%
ldconfig: File /usr/lib/libnss_files.so is empty, not checked.
:: Running post-transaction hooks...
(1/4) Arming ConditionNeedsUpdate...
(2/4) Notifying arch-audit-gtk
(3/4) Updating icon theme caches...
(4/4) Updating the desktop file MIME type cache...
root@bastelfreak-nb ~ # puppet resource package htop ensure=installed source=/var/cache/pacman/pkg/htop-3.5.0-1-x86_64.pkg.tar.zst
Notice: /Package[htop]/ensure: created
package { 'htop':
  ensure   => '3.5.0-1',
  provider => 'pacman',
}
root@bastelfreak-nb ~ # pacman -Q htop
htop 3.5.0-1
root@bastelfreak-nb ~ #

So I would say your patch is valid and improves the situation. Can you please sign the commit so we can merge it?

[fmichea]

Alright thanks for getting back to us, I have updated this PR with a SSH signed commit with Signed-off-by line.

As far as the problem overall, I agree with you this change is more correct than what is on main branch however I think that the fact this does not lock in the version for upgrades (pacman -Syu does not honor the pin) and it won't downgrade an installed package is definitely something that requires a follow-up in my opinion.

Let me know if I am still missing anything to allow for merging.