[solved] pacman new package updates notification

Strubbl · 2020-11-13 17:25:25

Hello, i am searching for way to get a mail notification when there are pacman updates and which packages need an update. So something like apticron on debian-based systems.
Which is the tool on Archlinux to achieve this?

Last edited by Strubbl (2020-11-13 17:41:34)

icar · 2020-11-13 17:27:35

You have `checkupdates` from the package `pacman-contrib`. You can use its output to check for updates. Then you can automate that with a systemd-timer, a cronjob, etc...

Scimmia · 2020-11-13 17:35:03

Has it been more than a day since you updated? If so, there's a good chance you have updates, no tooling required.

Strubbl · 2020-11-13 17:38:25

Scimmia wrote:

Has it been more than a day since you updated? If so, there's a good chance you have updates, no tooling required.

Yes, i know that from my Desktop PC Archlinux installation. But i have also a minimal installation on another device and for that i would like to have a reminder cause there are no daily updates available.

Strubbl · 2020-11-13 17:41:20

icar wrote:

You have `checkupdates` from the package `pacman-contrib`. You can use its output to check for updates. Then you can automate that with a systemd-timer, a cronjob, etc...

awesome, that's what i was looking for. Thank you.

Trilby · 2020-11-13 17:54:18

I also don't get the need. Even if there isn't an update available every day, there's no harm in just runing `pacman -Syu` everyday. If there's nothing to do, it will simply tell you that. Or if updates really are less common on that machine, run the update every two days, or once a week. Just pick the interval that works for you. Even if you go with weekly, are you really worried about some package having a non-applied update for several days such that you'd need to email notification to update as soon as it hits the repos?

Strubbl · 2020-11-13 22:43:28

Trilby wrote:

there's no harm in just runing `pacman -Syu` everyday. If there's nothing to do, it will simply tell you that. Or if updates really are less common on that machine, run the update every two days, or once a week.

of course there is no harm. but you have to remember to do it and you have to do it manually. it's just nice to have a reminder that's there's something to do. it's the way i organize my todos, via mail. a machine in the basement is easy to forget for a month if it just works.

Last edited by Strubbl (2020-11-13 22:44:46)

GaKu999 · 2020-11-14 02:49:18

I did a proof of concept because I was bored.

The script: https://github.com/GaKu999/dotfiles/blo … bin/chkupd
The service: https://github.com/GaKu999/dotfiles/blo … pd.service
The timer: https://github.com/GaKu999/dotfiles/blo … kupd.timer

Modify as needed, you need fakeroot, libnotify, the script to be executable of course, and a notification daemon listening.

I consider once per hour quite heavy, but since I don’t use my computer for a long time per day that suits me, you may change it for a long running computer.

Considering you want per mail, you can do minor changes and turn it into a system service, sending with s-nail or msmtp, but for that case, the work is less than desirable or redundant, since server maintenance should include pacman -Syu anyways.

I only have it to get the updates in my WM.
And if they are up to certain threshold I proceed to the ritual.

Last edited by GaKu999 (2020-11-14 17:49:01)

twelveeighty · 2020-11-14 16:34:57

@Gaku999: just curious, why not use `checkupdates` instead of "pacman -Sy" in a fakeroot?

GaKu999 · 2020-11-14 17:23:09

twelveeighty wrote:

@Gaku999: just curious, why not use `checkupdates` instead of "pacman -Sy" in a fakeroot?

me wrote:

I did a proof of concept because I was bored.

Now on a more serious note, see the shebang? My sh is dash, yet checkupdates uses bash, if I call checkupdates I spawn bash to do the same, so I cutted up the middle man.
Otherwise I tend to avoid interfacing with the output of a script with another script, to avoid spawning subshells.

Trilby · 2020-11-14 17:32:39

And checkupdates is 115 lines, the equivalent portion of the script above is under 20 lines.

Never reinvent the wheel - but always feel free to make better wheels!

Last edited by Trilby (2020-11-14 17:33:20)

eschwartz · 2020-11-15 00:35:35

GaKu999,

Your script is very broken if you don't have XDG_CACHE_HOME defined in the environment -- per the XDG spec, you need to use ${XDG_CACHE_HOME:-$HOME/.cache} as defining it is optional and it has a fallback location. The very last thing you want to do though, is try writing to /pacman/updates

As for reimplementing 115 lines worth of checkupdates... it is 405 lines if you count its use of libmakepkg's message.sh library for printing "==> ERROR:" in color, and parseopts.sh for implementing command line options with GNU-style longopt support (surprisingly complicated).

Why the need for options? Because you get 'checkupdates --download' for free, in order to download the updates into the cache. And forking once to bash is really not wasteful... I see no harm in replacing 10 lines of your script with 'checkupdates > $tmp || exit'

It's quite frankly not "making a better wheel" to take a program and strip it down (and maybe introduce bugs when you assume environment variables are set, which aren't), removing features but copying half the code just to let it use sh instead of bash. Unless you actually have a compelling urge to remove bash from your system.

The code exists, it's unobjectionable, it's already very lightweight (so much so that you directly copied it into your script), and someone else is maintaining it for you.

"I don't like spawning subshells" doesn't really seem like a compelling reason to ignore that, especially for a mere rewrite of the existing external code...

If you just want notify support, did you consider the learning experience of improving the existing script, followed by the sharing experience of submitting a patch to add a --notify option to checkupdates which will then be distributed to tens of thousands of users?
As opposed to the learning experience of copy-pasting a few lines into a new script, followed by improving the new script for your own and one other person's use.

It should be a very simple addition...

...

Random aside: #!/usr/bin/env sh
I know people use /usr/bin/env (not guaranteed to exist) to spawn bash (which is not in /bin on the *BSDs, or to find *updates* to bash 4 on macOS) by using its PATH-searching capabilities.
I haven't seen people use it to find /bin/sh though, and it seems rather wasteful to invoke env for this. Given that for sh, you exclusively care that it must be "a portable implementation of sh", you don't care about updates.

GaKu999 · 2020-11-15 01:27:15

eschwartz wrote:

Random aside: #!/usr/bin/env sh
I know people use /usr/bin/env (not guaranteed to exist) to spawn bash (which is not in /bin on the *BSDs, or to find *updates* to bash 4 on macOS) by using its PATH-searching capabilities.
I haven't seen people use it to find /bin/sh though, and it seems rather wasteful to invoke env for this. Given that for sh, you exclusively care that it must be "a portable implementation of sh", you don't care about updates.

I was thinking about what shebang to use, but I haven’t decided whether to call for /bin/sh, /use/bin/sh or use env. So I use env which is there in the meantime (eventually I’ll use /usr/bin/sh), do note that I have a habit of doing weird things.
I once coded every script without normal conditionals.

EDIT: As peer feedback, it seems I had a wrong concept of the existence of /bin as a symlink, feex.

eschwartz wrote:

Your script is very broken if you don't have XDG_CACHE_HOME defined in the environment -- per the XDG spec, you need to use ${XDG_CACHE_HOME:-$HOME/.cache} as defining it is optional and it has a fallback location. The very last thing you want to do though, is try writing to /pacman/updates

me wrote:

Modify as needed

This was a disclaimer, if you didn’t touch it shame on you!
I define environment variables per-user with pam_env, somewhere there is a environment.conf that you can see, I started messing around with a weird .local.
In any case, these aren’t my dotfiles for a random reason. , expect them to be weird and working on my personal environment.

If one of my globals is not defined I have bigger problems that a broken script.

Now seriously, I choose do or die, if something is bad, my fault for not making it be there. Talking about the variable.

For the rest, neither mako nor notify-send care about colors, and I didn’t want any of the options nor fancy logging.

Regarding notify support, I think that would be clutter for checkupdates, that’s why I choose to read manpages and see how checkupdates called pacman as user, the rest was simpler once I discovered that fakeroot was a thing.

Also:

me wrote:

Otherwise I tend to avoid interfacing with the output of a script with another script.

Take it as my one of my weird rules.
Not that they are written in stone.
But still, they make me learn stuff.

eschwartz wrote:

Unless you actually have a compelling urge to remove bash from your system.

brain wrote:

bash interactive shell, no make bash scripts, avoid using bash scripts if possible.
scripts be posix, scripts call for sh, sh should be posix and nothing else.

I’m sorry if I didn’t talk properly or communicated clearly, I’m quite busy tinkering with hardware for the first time in months.
This post will probably get pruned to clearness once I assemble asgard back into place.

Last edited by GaKu999 (2020-11-15 04:24:47)

Trilby · 2020-11-15 01:28:02

Eschwartz: Simple scripts should be simple. Being able to use complicated parameters is not a selling point. By that logic, checkupdates should also brew your coffee (and it'd definitely be one of those K-cup style things, definitely not the less wasteful, better tasting, sustainable, affordable, environmentally friendly option of just pouring water over grounds without a chunk of plastic in the way).

Every useful tool makes assumptions. The effort to eliminate assumptions so the tool can do everything in every case makes the tool worth less.

Though on the shebang I completely agree. The entire functioning of the script assumes it is running on arch (or an arch-like OS), and in such cases, the presence of /bin/sh is at least as well assured as the presence of /usr/bin/env.

EDIT: for the follow up: why /usr/bin/sh and not /bin/sh? If you want portability in your scripts in general, /bin/sh is the better option of the two (and 4 characters shorter). Are there systems that use /usr/bin but do not have a /bin symlink? There ARE systems that use /bin but do not have a /usr/bin. So why add four characters that will do nothing in a vast majority of cases, but may cause trouble in others?

GaKu999 wrote:

Now seriously, I choose do or die, if something is bad, my fault for not making it be there.

This is (or at least can be polished into) a good philosophy. Perhaps there is a general name for the concept, but I find it best exemplified by the pythonic approach of try -> except rather than check, check, check, do. Perhaps a general name is "it's easier to ask forgiveness later than permission now." Although keep in mind the sound pythonic application of this philosophy is not try->potentially-crash-and-burn, but try->except. Perhaps yours is the yoda version of the python approach: do or do not, there is no try!

GaKu999 wrote:

Regarding notify support, I think that would be clutter for checkupdates

But we've already established, the guiding principle behind checkupdates is embracing clutter!

Last edited by Trilby (2020-11-15 01:36:31)

eschwartz · 2020-11-15 02:42:44

GaKu999 wrote:

I was thinking about what shebang to use, but I haven’t decided whether to call for /bin/sh, /use/bin/sh or use env. So I use env which is there in the meantime (eventually I’ll use /usr/bin/sh), do note that I have a habit of doing weird things.
I once coded every script without normal conditionals.

As Trilby said, why ever use /usr/bin/sh -- I'm not aware of a single system providing one, either they will provide exclusively /bin/sh or both directories will be symlinked together so either one will work, but even in that latter case it is "correct" to use /bin/sh and /usr/bin/sh only exists by accident (including on Arch, before bash 4.2.045-2 we added bash/sh symlinks to /bin only, but with the /usr move, we only created /usr/bin/sh as the canonical realpath of /bin/sh).

And glibc (and probably most libc implementations in general) hadcode /bin/sh for e.g. system()/popen(), shebang-less scripts, etc.

/bin/sh isn't strictly required by POSIX, but POSIX does require sh to be a disk executable available somewhere on $(getconf PATH), and doesn't describe the path to env either.

The only system without /bin/sh as the path to POSIX sh is I think Solaris, but in their case they have a bourne shell for /bin/sh and a POSIX shell at /usr/xpg4/bin/sh, and #!/usr/bin/env sh will return the bourne shell, not the POSIX one.

tl;dr Do not rely on env to return a POSIX shell in a shebang, it will only successfully do so on systems where /bin/sh is the answer. Do not rely on /usr/bin/sh, since it likely only exists by accident.

/bin/sh and /usr/bin/env are the two "exists everywhere by convention" disk paths to executables.

GaKu999 wrote:

eschwartz wrote:
Your script is very broken if you don't have XDG_CACHE_HOME defined in the environment -- per the XDG spec, you need to use ${XDG_CACHE_HOME:-$HOME/.cache} as defining it is optional and it has a fallback location. The very last thing you want to do though, is try writing to /pacman/updates
me wrote:
Modify as needed
This was a disclaimer, if you didn’t touch it shame on you!
I define environment variables per-user with pam_env, somewhere there is a environment.conf that you can see, I started messing around with a weird .local.
In any case, these aren’t my dotfiles for a random reason. , expect them to be weird and working on my personal environment.
If one of my globals is not defined I have bigger problems that a broken script.
Now seriously, I choose do or die, if something is bad, my fault for not making it be there. Talking about the variable.

This was true only until you started sharing it with people and expecting it to work on their personal environment too

GaKu999 wrote:

Regarding notify support, I think that would be clutter for checkupdates, that’s why I choose to read manpages and see how checkupdates called pacman as user, the rest was simpler once I discovered that fakeroot was a thing.

Again as Trilby said -- checkupdates is intended to be cluttered with options to do various optional things a wide variety of users want. The option would be welcome, trust me.

GaKu999 wrote:

Also:
me wrote:
Otherwise I tend to avoid interfacing with the output of a script with another script.
Take it as my one of my weird rules.
Not that they are written in stone.
But still, they make me learn stuff.
eschwartz wrote:
Unless you actually have a compelling urge to remove bash from your system.
brain wrote:
bash interactive shell, no make bash scripts, avoid using bash scripts if possible.
scripts be posix, scripts call for sh, sh should be posix and nothing else.
I’m sorry if I didn’t talk properly or communicated clearly, I’m quite busy tinkering with hardware for the first time in months.
This post will probably get pruned to clearness once I assemble asgard back into place.

Err... you'll have quite a hard time rewriting, say, makepkg, in POSIX /bin/sh. There's no reason to declare bash unsuitable for non-interactive scripts. In return for a slightly more bloated runtime, it can do very advanced things sh cannot. Like arrays.

Also traps on EXIT for bash reliably run whenever the script exits, no matter how it exits (save for the unrecoverable SIGKILL), on POSIX sh this is fraught with complication and you need to trap every possible signal. ISTR there were irritating caveats there too, though this might have been specific to traps that reset themselves from other traps but I cannot recall.

tl;dr if I can write something in POSIX sh I'll do so, but I also lose no sleep over writing complex bash scripts, of which I've written some pretty complex ones. I don't buy into the notion that anything too complicated for POSIX sh (but which bash can handle) should not be permitted to be written in bash but goes straight to python or C.

Trilby · 2020-11-15 03:14:28

eschwartz wrote:

I don't buy into the notion that anything too complicated for POSIX sh (but which bash can handle) should not be permitted to be written in bash but goes straight to python or C.

Nor do I, but I would say that a strong reluctance to use BASH can help better define where that line actually is. When people are quick to go to bash (so many linuxers default to bash for every script shebang regardless) then that line between what needs bash and what doesn't seems much much closer than it really is. Worse yet is when this spirals: someone defaults to a bash shebang, then since bash is already in use, why not use an array - even if a simple variable would work just as well, it's bash, so use an array.

I'm confident there is nothing that makepkg does that can't be done in POSIX sh ("does" meaning actual function or goals). I'd also not be surprised that if in it's early days makepkg development didn't follow the path described above: someone gave it a bash shebang "just 'cause" then others (or even the same person later) felt free to use bashisms in further development rather than doing things in a POSIX-portable way. And now we have a fully developed makepkg that would be quite a PITA to try to change to POSIX sh.

If early on there was more of a reluctance to use bash unless it was really necessary, this might not be the case. (And this also could imply different subjective thresholds for the meaning of "really necessary").

I'll also note as I've become more deliberate about avoiding bash (and raising the bar for what it means to be "really necessary") I've found that it is never actually necessary. The closest approach to needing bash is to use process substitution rather than a temporary file or named pipe - but neither temporary files nor named pipes are bad at all, and in some cases the temporary file version of a script is cleaner and easier to understand than the process substitution version.

Last edited by Trilby (2020-11-15 03:18:29)

GaKu999 · 2020-11-15 04:52:40

eschwartz wrote:

/bin/sh and /usr/bin/env are the two "exists everywhere by convention" disk paths to executables.

Alrighty, as said, I had a wrong assumption on /bin for being a symlink, feex.

eschwartz wrote:

Again as Trilby said -- checkupdates is intended to be cluttered with options to do various optional things a wide variety of users want. The option would be welcome, trust me.

Kay, I'll cook a patch adding --notify, but with checkup on the notifier, so libnotify is opt-depends, because it pulls other deps that get up to 3MiB.
Is there a ritual in the bugtracker or mailing it is enough?

eschwartz wrote:

This was true only until you started sharing it with people and expecting it to work on their personal environment too.

Alrighty then, you got me.

Trilby wrote:

Perhaps yours is the yoda version of the python approach: do or do not, there is no try!

Maybe, but I would do checkups if it's something meant to be for everyone.

I once had a lot of checkups everywhere, then realized I was wasting a lot on checking things I already made very sure where defined/done earlier.
So I decided to do things like that. At least for my own environment.

Still, that suits my philosophy for life. Trying is not enough!

Last edited by GaKu999 (2020-11-15 06:30:15)

adventurer · 2020-11-16 15:39:50

Strubbl wrote:

you have to remember to do it and you have to do it manually. it's just nice to have a reminder that's there's something to do. it's the way i organize my todos, via mail. a machine in the basement is easy to forget for a month if it just works.

Well, you could just combine checkupdates with desktop notifications. See here how I'm doing it. As noted in that post, I haven't found a way how to make this work under Wayland, though.

GaKu999 · 2020-11-16 15:44:57

adventurer wrote:

As noted in that post, I haven't found a way how to make this work under Wayland, though.

I use notify-send which is received by mako, it's not "oh fancy yada" but it matches my current WM setup.
Any notify daemon compatible with libnotify should work quite nicely.

zenity feels like an alternative to xdialog.

adventurer · 2020-11-16 15:54:15

GaKu999 wrote:

adventurer wrote:
As noted in that post, I haven't found a way how to make this work under Wayland, though.
I use notify-send which is received by mako, it's not "oh fancy yada" but it matches my current WM setup.

Ah, thanks! I had also tried notify-send but had not been aware of mako. I'm going to try that.

EDIT: I just noticed that mako only works with Sway. I don't think that I want that.

Last edited by adventurer (2020-11-16 16:09:40)

rmonico · 2021-11-21 08:44:32

I know this topic is already closed and is one year old, but I'd like to suggest this package for eventual travelers passing here: pacman-auto-update
It doesnt notify (by email nor desktop notification), and dont update aur packages (unfortunately). I thinking to clone this repo and make these changes.

Xyne · 2021-11-21 10:36:39

rmonico wrote:

I know this topic is already closed and is one year old, but I'd like to suggest this package for eventual travelers passing here: pacman-auto-update
It doesnt notify (by email nor desktop notification), and dont update aur packages (unfortunately). I thinking to clone this repo and make these changes.

This is a horrible idea and can break your system. Pacman updates sometimes require manual intervention and should remain an interactive process. Users are also expected to check the front-page news for information about possible interventions required for upgrading the system before upgrading.

To anyone else who finds this thread, I strongly recommend against automated updates.

Closing, as this thread has clearly run its course.

Arch Linux

#1 2020-11-13 17:25:25

[solved] pacman new package updates notification

#2 2020-11-13 17:27:35

Re: [solved] pacman new package updates notification

#3 2020-11-13 17:35:03

Re: [solved] pacman new package updates notification

#4 2020-11-13 17:38:25

Re: [solved] pacman new package updates notification

#5 2020-11-13 17:41:20

Re: [solved] pacman new package updates notification

#6 2020-11-13 17:54:18

Re: [solved] pacman new package updates notification

#7 2020-11-13 22:43:28

Re: [solved] pacman new package updates notification

#8 2020-11-14 02:49:18

Re: [solved] pacman new package updates notification

#9 2020-11-14 16:34:57

Re: [solved] pacman new package updates notification

#10 2020-11-14 17:23:09

Re: [solved] pacman new package updates notification

#11 2020-11-14 17:32:39

Re: [solved] pacman new package updates notification

#12 2020-11-15 00:35:35

Re: [solved] pacman new package updates notification

#13 2020-11-15 01:27:15

Re: [solved] pacman new package updates notification

#14 2020-11-15 01:28:02

Re: [solved] pacman new package updates notification

#15 2020-11-15 02:42:44

Re: [solved] pacman new package updates notification

#16 2020-11-15 03:14:28

Re: [solved] pacman new package updates notification

#17 2020-11-15 04:52:40

Re: [solved] pacman new package updates notification

#18 2020-11-16 15:39:50

Re: [solved] pacman new package updates notification

#19 2020-11-16 15:44:57

Re: [solved] pacman new package updates notification

#20 2020-11-16 15:54:15

Re: [solved] pacman new package updates notification

#21 2021-11-21 08:44:32

Re: [solved] pacman new package updates notification

#22 2021-11-21 10:36:39

Re: [solved] pacman new package updates notification

Board footer