- 1 Me
- 2 Packaging
- 3 FAQ
- 3.1 Should a daemon be automatically restarted when it fails?
- 3.2 Should I run Archlinux on my server?
- 3.3 How should I manage official kernel updates?
- 3.4 Why Never use -Sy when installing! is wrong?
- My profile: https://www.archlinux.org/developers/#seblu
- My website: https://seblu.net
- My twitter: https://twitter.com/seblu42
- My twister: @seblu
- My GPG key fingerprint: B81B 051F 2D7F C867 AAFF 35A5 8DBD 63B8 2072 D77A
Add this in your /etc/pacman.conf
[seblu] Server = http://seblu.net/a/$repo/$arch SigLevel = Required TrustedOnly
PKGBUILD can be found here.
Instruction on a separate page: ARM
This is my guidelines that I try to apply in my packaging duties.
Of course, everyone should follow them.
They come from my years of packaging for Archlinux.
- Put all needed dependencies. You should not assume that another package has the same requirement and do the job for you. It can be dropped without notifying you.
- Don't use versioned deps. That's a sad, but shared way of doing in Arch.
- Quotes variables with spaces. In particular $scrdir, $pkgdir. There is no allowed space in $pkgname and $pkgver.
- Use single quotes when there is no needs for double or back quotes. (e.g 'x86_64')
- Don't cd in $srcdir at the beginning of prepare(), build(), package(). It's a defacto standard.
- Don't use .. (double dots) inside a path. In particular don't
cd "$srcdir"/linux; cd ... You will not go where you expect if linux was a symlink.
- Use install instead of cp whenever possible.
- Only lowercase in $pkgname
- If upstream provides a signature, use it!
- Never put base-devel as a dependency.
- Don't use tab, use spaces.
- No trailing whitespaces.
- Comments are free.
- Run namcap on your PKGBUILD and on your built package.
- Run checkpkg after bumping a package to a new version.
- Don't put informal messages in post_install() functions. Only mandatory messages. Howtos go into the wiki.
- If you ship systemd unit files, name it lowercase.
Here is my answers.
Should a daemon be automatically restarted when it fails?
In a nutshell, this should be the last resort and not the default.
The expected behavior for daemon is to do its job without crashing, and exit properly when it finishes. Unfortunately, bugs and others cosmic dusts cause software to misbehave.
The question of making a daemon automatically restart will never come with a reliable one, but with a shaky daemon, more than once. And if it's not expensive to restart it automatically, maybe it's also a good idea to do the same for all daemons. Here we are.
From my experience, most crashing daemons require user intervention before falling back to work. It can be caused by a misconfiguration (e.g upgrades, typo, ...), a programming error (leading to a segfault), missing libraries (packaging error), etc. So restarting it automatically, doesn't help much. Quite the opposite, it causes unneeded resources consumption (logs, forks) and make the debugging more difficult.
Even worse, restarting a daemon which fail may hides a degraded service. For example, when the service crashes for 20% of your customers because they have a back-quote in their login, or, it's damn slow because it restart twice before completing a task. There is plenty of errors that can be masked by a non-failing service, that's why a sane default is to not restart it when its creator didn't handle the case.
Of course, there is poorly coded daemons, which require to be restarted frequently because they crash. In that case, auto-restart is an option. We have better things to do than restarting them manually. But this is not a default, it's targeted to a particular daemon, which crash for a known reason.
Some corner case may be found in vital daemons (e.g sshd), which are required to get back the control of your host. When you loose it, you cannot troubleshoot. In this case, restarting it may be a comforting behavior, albeit...
As a consequence, I suggest to choose a default which doesn't try to make a non working daemon looks like a working one. If the administrator want it, let him override it.
Should I run Archlinux on my server?
Yes it's a good idea to run Archlinux on your server but read this before:
How should I manage official kernel updates?
Upgrading the kernel, you are in trouble!
During its upgrade, the official kernel package (called linux) removes (or replaces) modules in /lib/modules/$(uname -r). The running kernel $(uname -r) is still the same. As a consequence, you (or udev) cannot load kernel modules anymore. This may lead to difficult to track issues. So, you should reboot on your new kernel after each update.
This is boring because:
- This will downtime your service;
- You're in the middle of something;
- You don't need the new kernel now;
- There is several updates by month;
- It breaks your uptime. :)
Reboot into your new kernel, you may go to hell
Unadvertised users run only one Linux kernel on their computers. After an upgrade and a reboot, the computer might be "broken". This can be a consequence of a bug directly inside the kernel, or an error during the upgrade process.
Archlinux official linux package doesn't provide you a correct solution for this. You workaround this by using the linux-lts kernel package to have a backup kernel (if your hardware is supported).
A new hope (Episode IV)
To fix the two previous issues, I suggest you a different approach. You could use a versioned kernel package like linux-seblu-3.x.y (you can find a copy in my repository). No package upgrades broke the module ABI and new versions are in a separate package.
Why Never use -Sy when installing! is wrong?
In a nutshell: this article misguides you.
No versioned package
The real issue behind all of this: We try to avoid version dependencies in Archlinux. Not that pacman cannot manage them. But developers decide to not use them when there is no strong needs. Mainly to:
- Simplify the package maintenance (reduce the workload / the quantity of bug / etc);
- Speed-up dependency computation.
It's like that far before I joined the project, so don't blame me!
Consequences: there is no way to know which packages needs to be updated when you upgrade another one.
The safest and recommended way is: When you upgrade or install a package, be sure that your whole system is up-to-date. If not, some dependencies can be broken, like a library, a module, a database format, etc.
In all case, be sure to have an upgraded system before report any issue in the bug report system.
Why are you misguided?
- Installing a new package don't pull the last version of an already installed library. When there is a soname bump, only the new installed software should be broken, and not your entire system. The running service should be fine. There are exceptions when versioned dependencies are used.
- The cause is not the -y option. It's because your system was not upgraded before you install a new package.
- That doesn't mean that you must upgrade the whole system each time you install a package. But if you don't understand why, do it.
- When you are using AUR packages or when your favorite desktop sync the database frequently (to show you the number of upgrades), you may break your system with -S. The -y option will not protect you.
- Firefox is not linked against readline.
- Core programs (bash, pacman, systemd) use versioned deps to prevent an unbootable operating system.
- A loudly broken soft is better than a silent broken soft. Because you fix it quickly.
- Upgrading the whole system is a dangerous operations (especially on servers). New software version could be bugged! A default policy to upgrade the whole system for each new installed package to prevent broken package is crazy.
- Archlinux is not crap, it's targeted to power users.