`pamac search` confused when local version is installed more recent than repo version


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.

What is the command you used to install the local version of rclone?

Exactly. There’s nothing to “fix”. Let me show you why:

First, make sure you are up to date and your local database is up to date:

sudo pacman -Syu && sudo pacman -Fy


Query the repo package:

pacman -Si rclone

1.63.1. Right?

Query your local version:

pacman -Qi rclone

1.64. Right?

There you have it. You’ll also notice when you ran pacman -Syu, it said something like,

 warning: rclone: local (1.64-1) is newer than extra (1.63-1)
1 Like

Exactly. This 1.64 came from some as yet unspecified source, and not the Arch repositories, as postulated.

If package is from a third-party source it is not a Manjaro problem

rclone 1.64.0-1 is available in Manjaro Testing and Unstable repositories

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.

If you had switched to Testing or Unstable branches rather than installing a third-party package there would not be any confusion in pamac responses

$ pamac search --no-aur rclone
rclone  1.64.0-1                                                                                                   extra
    Sync files to and from Google Drive, S3, Swift, Cloudfiles, Dropbox and Google Cloud Storage

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
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

with pamac search -r package possibly reporting

package <repo version> [Not installed] extra

Or, adding the package source (my 2 cents).

Switching to Testing or Unstable branches would not create any confusion


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?

In terms of reporting, it was a response to:

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.

Strawman fallacy does not make sense

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

@callegar So since no one addressed the actual issue, my advice is: use pacman and forget pamac. It’s what grownups use. :stuck_out_tongue:

1 Like

… unless those grownups rellish pwetty icons.

pacman is not needed if user can read either rclone — Arch manual pages
or Switching Branches — Manjaro Wiki

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 -Ss rclone
extra/rclone 1.64.0-1 [installed: 1.63.1-1]

$ pamac search --no-aur rclone
rclone  1.64.0-1 [Installed]             

Notice the difference?


Are your mirrors/packages up to date?

$ pacman-mirrors -G; pacman -Si rclone; pamac search --no-aur rclone
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

Manjaro 2023-10-09 Stable Update ($934) · Snippets · GitLab

:: Different sync package(s) in repository extra x86_64

                            PACKAGE           2023-10-04           2023-10-09

                             rclone             1.63.1-1             1.64.0-1

Doesn’t matter, it was an example.
Here, another one, fixed rclone version manually this time :smiley:

$ pacman -Ss rclone
extra/rclone 1.64.0-1 [installed: 9001-1]

$ pamac search --no-aur rclone
rclone  1.64.0-1 [Installed]