I have noticed that pamac search gets confused when you have an installed package that is a more recent version than a repo package.
Example: I use rclone. Because I need to test the latest version and I have noticed that: (i) it is available on arch and (ii) the version in manjaro comes from arch, I have downloaded the PKGBUILD from arch and built the package locally with buildpkg. Then I have installed the resulting package with pamac.
With this, I locally have rclone 1.64, while the manjaro stable repo is still at 1.63.1.
Now, if I pamac search rclone, the tools says that rclone is available at 1.63.1-1 and installed, but this does not correspond to the truth, because the installed version is not 1.63.1-1.
Maybe the tool should be fixed to handle this corner case.
Indeed with pacman everything is fine, because there are two ways to query, pacman -Si to query the repo database that is synced locally and pacman -Qi to query the local database. If appropriately queried pacman will also kindly tell you that you have a local version newer than the repo version.
The problem I was pointing at is not with pacman, it is with pamac that on its single search option, will pretend that the version you have installed is the repo version even if you have a local version newer than the repo (and this also happens with pamac search -i that is explicitly told to look at the installed packages only). I think that this is confusing. In case you had for any reason to install local packages overriding the repo ones it will not make this fact evident as you search for packages. This is why I was reporting this fact, in case anyone might have found it worthy improving the pamac search -i output for cases like this.
I have an example - which is using a third-party repo (my dev repo)
Depending on where in pacman.conf the repo is listed (before or after official repo) - in my case it is listed after official.
$ sudo pacman -S nixrepo/pacman-mirrors
[...]
Package (1) Old Version New Version Net Change Download Size
nixrepo/pacman-mirrors 4.23.2+3+g4148c3d-1 5.0.1-1 0,01 MiB 0,21 MiB
[...]
Querying pamac for version info it will show me that 4.23 is in core but not installed
$ pamac search -i pacman-mirrors
pacman-mirrors 4.23.2+3+g4148c3d-1 core
Manjaro Linux mirror list for use by pacman
Even though I have a later version installed
$ pacman-mirrors --version
Version 5.0.1
That doesn’t seem to be any cause of confusion but rather the expected behavior as pamac is not pacman.
$ sudo pacman -Syu
[..]
:: Starting full system upgrade...
warning: pacman-mirrors: local (5.0.1-1) is newer than core (4.23.2+3+g4148c3d-1)
[...]
But I see what you mean as using a generic search will display the v4.x installed - but that is likely due to pamac not looking at the version - but only the package name.
$ pamac search pacman-mirrors
shiny-mirrors r269.0e59fd0-1 extra
An alternative to Manjaro's pacman-mirrors, rewritten in Rust! A tool to find the best mirrors for
you!
msys2-pacman-mirrors 20221016-2 AUR
MSYS2 mirror list for use by pacman
pacman-mirrors-helper-git r94.f5340a4-1 AUR
A wrapper simplifying repository management and mirror selection using the rate-mirrors tool.
pacman-mirrors 4.23.2+3+g4148c3d-1 [Installed] core
Manjaro Linux mirror list for use by pacman
The difference is because pamac is not pacman - as pamac is designed to simplify the interaction with the package metadata.
So in my opinion, the search is not confused, it is simply a matter of functionality and the displayed information.
Indeed, the initial title of my post was probably misleading.
Still, wrt
I think that it would be good to avoid presenting the user information that might appear confusing.
Example: I have admin rights on a machine. I manually install a single package built locally using buildpkg over a repo package (note that there may be many legitimate reasons for doing so, for instance to have some feature before it gets to manjaro stable, while not switching the whole of the machine to testing or unstable). Some other users on my machine have no admin rights and happen to use the package. They encounter problems, so they try to query where the package comes from. They obviously use pamac, not pacman, because they want the *simple" tool. However with it they are lead to think that the package is at a different version than the real one and miss the crucial fact that the package is from the local admin rather than the distribution. This may lead to the problem being reported incorrectly.
For this reason, I think that pamac search package for this specific case would better report
package <actually installed version> [Installed] local
rather than package <repo version> [Installed] extra
Switching to testing or unstable would move the whole of the system to testing or unstable, I guess, which is not wanted. The goal here is the occasional update for a single package building it against current stable.
Can you please elaborate on this, I may be missing something. Do you mean creating a custom repo?
Adding the package source should also help identification of a given package, when from a foreign (not from Arch) source; for example “installed from AUR / local Flatpak / FlatHub”, etc.
If a hypothetical user is savvy enough to spot incorrect version number in Pamac, but not savvy enough to check the package in pacman or rclone --version How did the user know the version number is incorrect? following the release notes on Github or online documentation?
Even if this were to happen, any confusion could be dispelled by system admin explaining: rclone has been updated using an out-of-branch package
Pamac will show the correct version number when later version is released to Stable branch
If the goal was more specific to getting a later version of rclone I would suggest using the built-in rclone selfupdate command rather than downloading package from an anonymous source
(I suspect unnamed source is chaotic-aur or similar ?)
The less specific goal of updating any single package is likely to fail for some packages due to dependency issues.
But if a user wanted to install a later version anyway, I suggest they get packages from Manjaro Testing or Unstable repositories
How is that relevant to any of this? OP basically reported (a minor) bug (or, well, a lack of oversight) and all of you are dreaming about switching branches and whatnot.
Where something was installed from is irrelevant.
$ pacman-mirrors -G; pacman -Si rclone; pamac search --no-aur rclone
stable
extra/rclone 1.64.0-1
Sync files to and from Google Drive, S3, Swift, Cloudfiles, Dropbox and Google Cloud Storage
rclone 1.64.0-1 extra
Sync files to and from Google Drive, S3, Swift, Cloudfiles, Dropbox and
Google Cloud Storage
