Indeed.
However… running pkgfile -u updates it’s own redundant database: /var/cache/pkgfile/.
Of course they do. Unless I’m misunderstanding you?
For example, pacman -Ql will query the local package database and pacman -Fl will query the local file database.
Youve got that mixed up.
For “Which package owns this file that is on my system”, use pacman -Qo
ex:
pacman -Qo /usr/bin/firefox
Similarly you may print what a package has provided.
ex:
pacman -Ql firefox
For ‘what package not installed on my system would provide a file’ you can…
ex (in this case combining the update and the search, and using regex):
sudo pacman -Fyx 'bin/firefox'
(and similarly, as pointed out above, -Fl for “what files would a package provide”)
Of course -F (database) searches all … so it isnt exclusive to non-installed packages … theres just not much use/reason for it with already installed packages.
So guys, the more I read from you here, the more confused I get. Let’s be clear: Is @Yochanan 's approach
the best possible or not?
My English understanding is dependent on DeepL and that doesn’t really improve the situation here.
Yes. He is a manjaro developer, he should know. If he says so than it should be the best. I just was not sure at the beginning.
OK, done.
You are correct pacman -Qo answers the question which package owns the file on the local system. I am so use to using -Fx and mentally filtering.
That’s why I used the word “might” 
The .files represent the state of the repo, and the more I read I think that is the intended purpose, just not how I’ve used it.
Here’s a scenario:
If the files in the packages on the repo are the same from 01/01 and 01/15, it is a happy accident that .files matches .db contents. But if they aren’t, then the .files represent the repo and not the .db files.
I’ve always used .files as a representation of the files in packages that exist in my local sync databases, not the repos.
If a user runs pacman -Syu on a daily basis, it would make more sense to me to run pacman -Fy on a timer. But if a user updates monthly, it would make more sense to run pacman -Fy at that time so the .files match the .db. That is just how I’ve used pacman -Fyx over time. I do understand @cscs examples. The arch wiki on pkgfile does say, “pkgfile is a tool for searching files from packages in the official repositories.”. The man page isn’t as direct.
NOTE: .files and .db are shorthand for the files in /var/lib/pacman/sync/ which are managed by pacman. I used pacman -Fy, but I believe the same would be true for pkgfile -u, except files are in a different location.
From pacman man page for -y:
From pkgfile man page for -u:
I haven’t gone any further than reading the man page and arch wiki. But to me, it reads, if the repo is newer, the .files will be updated to reflect the repo at that point in time. If that is the desired outcome, the timer should be run.
This is similar to pamac-mirrorlist.{timer,service}. imho, the mirrors should be manipulated just before a user updates to reflect the status of the mirrors at that point in time. So in summary, the consecutive steps become (without timers):
Read Announcement
pacman-mirrors -f5 # continue only if up to date available mirrors
pacman -Syu
pacman -Fy
DIFFPROG=meld pacdiff
pacman -Qm
pacman -QdtIf I’m in error, please correct, but otherwise I don’t want to take the focus off the OP. I hope the discussion was of value.
If you have already created your mirror pool with you region, etc. then you may wish to just use -f.
In my case thats just 11 mirrors in my region providing https.
If you want to be able to edit the files using, for example meld, then you probably want -s there.
Though … I notice other commands are missing sudo, so maybe this is elevated privileges to begin with?
If, like the next 2, you just want it to print then you could use: pacdiff -o
As mentioned above - this will print foreign packages, then print orphans.
And then
yay -Syu
to rebuild what AUR packages are found with pacman -Qm
If you just did system updates … then follow it with aur-only. ex:
paru -Sua
…and if orphans are detected with pacman -Qdt one probably want to remove them with
sudo pacman -Rsu
So the ultimate forum approved ™ update routine of an advanced user should be something like
Read Announcement
sudo pacman-mirrors -f5
sudo pacman -Syu
sudo pacman -Fy
DIFFPROG=meld pacdiff -s
pacman -Qm
pacman -Qdt
sudo pacman -Rsu
yay -Sua
Five comments.
The last line, the AUR helper probably should be agnostic: yay, pamac build, paru …
Some place mention that it is important to actually read the output of the commands and pacdiff.
Add an item for reboot. Wasn’t systemd suppose to make boots faster 
Add an item to view the journal and coredumps, journalctl -b -p3; coredumpctl. The goal is to find any issues as timely as possible after an install if any exist.
Last point, @cscs had a good observation regarding pacman-mirrors. So, what is the best form? The goal is to rank mirrors and validate them. Rhetorical questions - But which mirrors though? All/default mirrors? The custom mirror list (assumes user has run the appropriate pacman-mirrors)? How often should the custom mirror list be updated. Some folks never change it, but they may only have one option too
man pacman-mirrors, just do pacman-mirrors --country Denmark --timeout 5 (change Denmark as applicable) before an update.There are 4 data files involved (explained in man pacman-mirrors):
Doesnt assume … its just less obtrusive that way.
Without a curated mirrors pool that would mean pinging mirrors globally … if you have sorted alread by, for example, region - then it would be a much smaller number, say ~12, meaning -f without limit would just be 12 mirrors pinged for ranking.
This might technically be best in that it will query pacman-mirrors for the current list of all mirrors in, ex Denmark and sort them, rather than simply re-sorting the ones already applied when creating the pool initially.
In this way the regular -f would just refresh mirrors you already have … doing all of your flags would mean you recreate the pool with current mirrors (adding and removing) and rank those.
Ex:
sudo pacman-mirrors -c United_States,Canada -a -P https
To be clear though … it is not necessary to do every time.
I will just do this every once in a while (think like once or twice a year maybe), or if I change locations of course. For me its enough to then just run -f every once in a while, but again, not very often as I will already have set my preferred/fastest mirror … it simply is not necessary to go sorting them again every day.
Btw -f selects only currently synced mirrors, so the list will be even smaller.
Actually i do not understand the need of many mirrors in that config file as it works now. The system always uses the first one to update. If the first mirror is not synced, but the server is up, it just says no updates. Even if the second mirror in the list is synced. The whole list is just there in case the first server fails, but sync is completely ignored. So actually 2 mirrors is all man needs.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.