Commands for package maintainance

Hi there :slight_smile:

I wrote a little script, that you can add to your $HOME/.config/fish/

It is one unified command to install packages and update your system.

We don't like partial updates, so updating our system before we install something, is always important. In order to simplify that, I combined both steps, together with AUR interaction.

Use add firefox to install from pacman`s repositorys.
And when they dont work it automatically tries at the AUR.

You can also use add to update your system and do not install anything.
It simplifies the commands you have to remember.

The script does avoid to install a package, if your system fails to update.
It prevents you from all damage, including bad sitcoms. :wink:

HINT: The option --skip-mirrorlist makes the update go faster and has a drawback:

Rating the mirrors is done, in order to ensure that you sync with an up-to-date one.
Otherwise, you could put your system in a partially updated state.

Garuda, in its infinite glory, does warn you when such a thing happens, and I personally have not experienced this once, despite me using the mirror rating quite rarely.

You can choose on your own, if you want that option, or not.

I am open to all input, as long as its well intended.

Thanks to the maintainer of fish, who does a wonderful job :raised_hands:

function add
  update --skip-mirrorlist &&
  paru -Sua &&
  echo \n "Update pkgfile database" \n &&
  sudo pkgfile --update &&
    if set -q argv[1]
    sudo pacman -S $argv
    if test $status -eq 1
    paru -S --aur --skipreview $argv

And here is a command that intelligently searches for your packages.

If the package you are looking for, is installed on your device, it shows a detailed view of it.
If the package exists in either the AUR or the official package repositories, it shows that, in sensible order.

And if the given parameter does not match any of that, it looks if the input can be found IN a package. That is especially useful when packaging.

function search
  pacman -Qi $argv
  if test $status -eq 1
  paru -Ss --aur $argv
  pacman -Ss $argv
  if test $status -eq 1
  pkgfile -vri $argv

I plan to add an optional choice at the end of the script, to send the device into a reboot.

We need to do that often, particularly at system level updates such as the kernel, systemd, and many similar services.

Ideally, this is an informed decision, and we can somehow determine whatever or not makes such rebooting necessary.

Does anybody know about this?

Look at garuda-inxi.

This is how yay and paru operate already - there's no need to use both pacman and paru, just running paru would do the job.

This means the script becomes essentially:

paru -S $argv
1 Like

I would still definitely skip mirrorlist updates though for something like this.
Also, I'd say it's not necessarily needed to update the system fully, as long as you don't update your pacman database.


Its partly true, as in paru being able to do both the job of pacman and paru.
I personally plan to use aura, and I like to leave the option to replace the AUR helper easily, without rewriting the pacman part.

On the other side: Updates in your example can fail, and paru would still install applications.
It does also not account for the case of being called without arguments, since it would still call paru without such.

Thanks for your hint about garuda-inxi. I assume this info is just visible, in case the reboot is needed?

Can you show me the string, that is appearing in such cases?
Thanks a lot

Well, if the local database is not needed, what happens when I install any package?
The mirror has the packages available, that are requested?

So, I can always install old packages, and that will be fine, so long as the database is old?
How is this exactly handled on the side of the mirror?

It was an example of the steps, not a concrete implementation with error handling etc.


Ah, I see. :slight_smile:

Might you elaborate, how the garuda-inxi command can help me, to figure out when a reboot is needed, due to package upgrades?

You mentioned this earlier.

Look at its source code.


I did find the source code and still lack any information on how to detect the need for a reboot.

You might confuse this with the feature, that shows us if the user has rebooted since the last update.

But this does not help with developing a feature that tells if its needed to reboot :smiling_face:

With KDE always :smiley:
Otherwise if you want after a kernel update.
If something does not work you should reboot first.
Why do you need an app/feature for that?


I would like to prompt the user, when needed.

Systemd is also such a case.

And, I think it has also already happened to fix issues on casual applications. So I guess there is no way to say this for sure and to be sure, we should just always reboot after an update. I could live with that, although I still want to ask, maybe does somebody know something for sure. If we can limit the amount of applications who need a reboot, can we track that for sure. :smile:

I seem to recall OpenSUSE would show a quick note at the end of a zypper update identifying what processes needed to be restarted. I don't know specifically how the mechanism works, but if you were curious you might be able to rummage around in the code and take a peek.

1 Like

I use tracer

sudo tracer -a
You should restart:
  * Some applications using:
      dropbox stop; dropbox start

  * These applications manually:

I check for a non zero return in my ansible scripts for some servers, and reboot.


Thanks a lot. This sounds useful, I will try and implement that.

One issue I see, is that this will also report e.g Firedragon and stuff.
Any idea, how I could differentiate between restarting applications and rebooting the machine?

Yes, that would be outside the scope of what I was doing.

My first thought, is you are going to want to direct the output through grep looking for linux kernels, *-ucode, systemd*, xorg, xf86-video-*, mesa, and nvidia. There are possibly more that you would want to check for, but they are not coming to mind at the moment. Again, this is what came to mind first, there may be a better solution.

1 Like

It's on line 45.