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. 
… 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
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
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 
$ pacman -Ss rclone
extra/rclone 1.64.0-1 [installed: 9001-1]
$ pamac search --no-aur rclone
rclone 1.64.0-1 [Installed]
Please do not focus on rclone: that was an example. The item I wanted to report is not about rclone that incidentally takes a nice --version option, but with the fact that pamac search may mislead its user to think that one version of a package is installed from the distro repo, when in fact a different version is installed locally.
Typically when people get confused, they won’t even realize that they are confused and ask. They might just take wrong decisions (e.g. reporting a bug upstream) based on their confusion.
The problem is not rclone
No need to be suspicious. That was not an anonymous source. The package came from a local build (practiced with Manjaro’s buildpkg tool) based on the official updated PKGBUILD used for unstable.
Should be exactly the other way round. If you take a single package from Testing or Unstable, things may easily fail because that package might have been built against different dependencies (also from testing/unstable) than the ones you currently have. Conversely, by taking the new PKGBUILD and building locally by buildpkg you assure that the package is built against your current packages from stable, namely you do what is commonly called a backport much less likely to fail.
Please, no, do not insist on the fact that you should move a whole system to unstable just because you need to quickly fix a single package via a backport. It is not relevant to what is being reported either.
I understand that backports are way less important on a rolling distro than in a non-rolling one, but when there is a need for it, the solution should be to temporarily build and install the backport locally (until the rolling distro has time to catch up), not to make the whole of your system more likely to break by switching to a more unstable rolling model (particularly if your system is multi-user).
To summarize: it was not my intention to create a long thread about rclone or the opportunity to switch a whole system to unstable.
What I merely wanted was to report a glitch in pamac (just assuming it might have been of some interest to the pamac developers, which I now tend to assume is not the case).
Namely, pamac appears inconsistent about package versions when you install packages built locally:
pamac search A will correctly report that A is available at version Rxxx and installed;pamac search B will report that B is available at version Ryyy and installed, when in fact it is installed at version Rxxx.There does seem to be the potential for confusion. Arrogantly suggesting something in the vein of “just use pacman instead” doesn’t solve that; despite it being an obvious alternative that I might even suggest, at times.
It also doesn’t matter where package was built. Someone can build it on the moon and send it to you.
Pamac shows you packages (you searched) from the repo and if a package with the same name happens to be installed, it shows you ‘[Installed]’ beside repo package.
Pacman does the same, with notable difference that it also checks versions, and in case those differ it will display ‘[installed: version]’. That’s it.
No. Then pamac (or pacman) won’t display anything, since that package doesn’t exist in repo. Remember, we are searching repo here. That ‘installed’ info is just a cherry on top.
It was a joke. But also, was it? Few years back that was something that was suggested by everyone all the time here. And for good reason. But then Manjaro figured “Hey, why not advertise our own product instead of pacman?”. And now do a search on pamac related problems.
So I don’t see how it’s arrogant to suggest something that will make your life easier. I agree, though, that it has nothing to do with this problem here, so that’s the ‘joke’ part.
It was a generalization, but, hey, if the cap fits… 
Some people do seem to like extra cherries; it’s a matter of taste, I suppose.
I have weasis-bin installed, it is not in the repo (it is in aur) and still:
pamac search --no-aur weasis
weasis-bin 4.2.0-1 [Installed]
Weasis is a free medical DICOM viewer used in healthcare by hospitals, health networks, multicenter research trials, and patients.
pamac seems happy to find it even if explicitly told not to look in aur.
In this case, the result effectively searches the repo’s and finds nothing; however, (as a courtesy more than anything else) reminds you that the package is already installed locally.
Does this make @anon51566685 's comment easier to understand?
You could test that by substituting ‘weasis’ for a package known not to be in the repo’s, but existing in the AUR; and that you have never installed; and running the same command.
Yeah, well… 
… hence post #15.
If a user switched branches or waited for stable update there would be no inconsistency in version numbers shown by one pamac-cli command
rclone is no longer viable as an example since Stable update 2023-10-09
IMO there is no reason for pamac packager to reconsider response in post #3: “Nothing to fix”
@anon51566685 I asked about where package was downloaded from to establish which section of the forum would be appropriate for this topic. Other than that, it does not make any difference where an out-of-branch package is sourced from
Really, this is not useful.
It has been told multiple times that rclone has nothing to do with the reported issue and that it was used just as an example and every new post seems to be about rclone.
It has been told multiple time that switching to testing or unstable is not a viable solution to issues in a single package: you do not want to loose stability in your whole system just to fix a single package. This is way Manjaro has an appeal as a curated derivative of arch. I do not think that that switching to unstable should ever be suggested without carefully considering the audience. Switching to unstable or testing is something that only experienced users working on non-production machines should consider doing. Iterating this suggestion only delivers the message that Manjaro is only for hobbyists who do not care about stability, which I do not think is the case.
When a single package has an issue, waiting for a new version to reach stable may be OK in most cases, but there may be cases where for some specific deployment it is not. Bundled upgrades come every 15-30 days and if a package is specially critical to the work flow in some deployment that time, that is normally totally OK, may be too much. Again not recognizing things like this delivers the message that Manjaro is unsuited to anyone needing to do real work on a machine, which again - from the many dedicated developers - I do not think is the case.
The common solution when a single package has an issue that needs an urgent solution and a new version or a patch fixing the issue is available from upstream is to backport the new version or the patch. This is commonly done by re-compiling the software against your current system. Arch derivatives make that extra easy, as it is often trivial to apply minor changes to the PKGBUILD script to pick the new version or to incorporate a patch. Manjaro makes that even better by providing the great buildpkg tool to build in a chroot (which, among other things, assures that the backport is consistent with the current distro and not influenced by anything you may have done locally). Rolling distros may make local backports particularly short-lived, but that does not totally cancel their usefulness in specific cases.
Backports are not updating only one application as it is meant in the quoted post “Never update only one application”. The quoted post is about an user taking a single app that is built against a different and more recent set of dependencies and so having trouble. Arch and its derivatives to not discourage backports: in fact, you even get tools helping with that, such as buildpkg. As a further example many of the packages you find in the AUR are in fact not completely unpackaged software, but more recent or otherwise patched versions of software that already exist in the official distro repos (e.g. many “-git” packages). When you build them you are in fact compiling them against the current set of dependencies that you have (which is basically the same thing as doing a backport against your current system).
The problem that was reported is that pamac always reports the package versions found in repos (including the AUR) which may be misleading when a backport is done locally, while pacman deals well also with this case, which is at worst an overlook from the pamac developers. It was not reported because the reporter absolutely needed to have that fixed (the reporter is totally happy about using pacman when realizing that pamac has issues), but thinking that the thing might have been of some interest to the pamac developers. Saying that there is zero interest would have been more than enough (even if it is unclear if this message comes from a pamac developer or someone talking for them). Alternatively, saying that the forum is no place for this and that this was to be reported on the pamac issue tracker would have been equally fine. Iterating that the reporter or everyone encountering that same overlook should move to unstable or discussing the uploading of newer rclone versions in the repo is at best out of scope.
While forget pamac seems a bit far reaching and aggressive to the pamac developers as a completely general advice (but obviously was a joke), using pacman and not pamac appears to be the correct suggestion for this specific usage case. Taking this as the solution.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.