I am not sure if I have a problem or not with this. I am wanting to check for updates on a periodic basis, and report them with a conky. ‘pacman -Qu’ provides a perfect output for my use (includes [ignored] on IgnorePkg iterms), but it is noted that it needs a pacman -Sy to provide pertinent and accurate results. So far, so good.
The first question comes from whether doing this sequence (-Sy and -Qu ) regularly leaves the system in a potentially vulnerable condition - as the database has been updated (synchronized), but the actual packages on the system have not. I had it suggested that installing something before actually performing the updates could lead to trouble, as the records and realities of dependencies may not match. As the ‘checkupdates’ script (from pacman-contrib) seems to go to some lengths to avoid this, I assume this can be bad. (!)
So -
I have several ideas for ways around the problem:
- Is there a ‘safe’ way to get the same output as pacman -Qu ? For instance, can the database be returned to the pre-sync’ed condition?
- Should I have the service I currently run (doing a pacman -Sy) on a timer be changed to doing a (modified) checkupdates redirected to a /tmp file for processing?
- Would it make sense to make an alias/bash function for package installation that performs a pacman -Syu before doing an install? It would save remembering
- Just script an alternative method for an ${execi} call that uses checkupdates to get the information?
Thank you for future enlightenment…
I’m not sure how accurate or rational that is from Arch standpoint, but in my scripts i always done
sudo pacman -Syy
Before checking…Haven’t seen problems yet (~ year of use)
Also, again in my experience if you install something like…I don’t know, just single terminal program without deps, like Hashdeep or something - it is pretty safe.
What Arch is trying to avoid is partial updates of stuff like Kernels / systemd / xorg / drivers / qt / de like KDE…That is not recommended at all
Refreshing the database creates the possibility of a partial update, but only if you install a package before updating. In this case the newly installed package can be newer than the rest of the system. So, what you should never do is pacman -Sy followed by pacman -S package-name.
But if you update your system after refreshing the database, you should be fine.
The script checkupdates allows you to safely check for updates without changing your local package database. It does that by creating a fakeroot environment in which the database is refreshed.
4 Likes
So - no opinion on which way is best to avoid the problem? I know a couple of them would work, but work is the operative word… I have a tendency to be a bit lazy, so I’m looking for the easiest one! Well- the easiest one that works well…
According to @Kresimir - checkupdates seems to be as safe as it can be!
I still will be dirty boy with -Syy and -Qu, i know my system after all…
So just checking won’t hurt 
checkupdates is perfectly safe, it leaves your local package database untouched.
For AUR, it is safe to use yay -Qua.
Any method of checking for updates that does not require you to enter your sudo password is safe. If you need to enter your password, it’s probably not safe and, depending on what you do after that, can lead to a partial update scenario.
4 Likes
I think a service running already has root privileges, so I don’t think I can get away with using that test for safety! 
I guess I’m in for some coding, then - or forcing an -Syyu update tied to any installs (by having a alias for install that calls for an update run first). I think I prefer the coding option - I don’t want to wait for an update just because I didn’t have jq on the system, and wanted to read a JSON file!
You can use checkupdates | wc -l with conky to give you the number of updates.
Yup - but I like to report on the number of [ignored] as well - so a little scripting will be required. Nothing complex, just what I already had is apparently dangerous over time. (service, timer, stepping through pacman -Qu output to get display info) - giving:
No real need for the extra info, but it felt more complete that way!
Sure, but having a service that repeatedly runs pacman -Sy is bound to get you into a partial update situation, whenever you install something without first updating. That’s not a good way to do it.
That’s why the coding. I’ll run checkupdates, redirected to a file, and process the file to produce the same output as the screenshot shows. Not sure whether to run that as a service or not - conky has its own timing mechanism…
Now - processing in bash, lua, C …hmm… The slow part is checkupdates anyway - so it probably doesn’t matter…
bash or pure sh (little faster) should be enough
I learned on AmigaDOS and Arexx - but bash should be doable
1 Like
Just a little update on this subject, in case anyone wanted to know…
I wrote a little script (bash) that:
- Checks it is on an Arch-based system
- Runs a modified checkupdates (leaves the [ignored] items in the list)
- Processes the output into a ‘report’ file in /tmp - for conky to read and display as shown above.
- Uses checkupdatesext (from @manuel) to generate a headered and formatted list in /tmp for
- Conky to display in a vertically smooth scrolling window…
- Added a pacman hook - triggered by update completion - to remove list and report files from /tmp, and create a report entry to say “System up-to-date”
- On removal of list files from /tmp, conky window for scrolling list disappears.
It even all works - on EndeavourOS, Garuda, Arch, and Arcolinux. Some people play with legos, I play with other people’s code blocks!
And here’s how it looks on one system:
Not exciting, but effective!
8 Likes