search

cloux / aws-devuan

systemd-free GNU/Linux for AWS Cloud Environment
Do What The F*ck You Want To Public License
20 stars 4 forks source link

Concern for symlinks #5

Closed Tank-Missile closed 5 years ago

Tank-Missile commented 5 years ago

I noticed kernel-cleanup, and possibly other scripts create symlinks in /usr/sbin. This is not good practice since package upgrades could overwrite those symlinks, unless I'm mistaken. Using /usr/local/sbin and equivalent directories instead might be cleaner.

cloux commented 5 years ago

The kernel-cleanup autorun script should definitely never create any symlinks, it only deletes files related to unused kernels. This is useful for automated AWS EC2 updates, where old kernels could easily fill up the limited EBS disk space. Since you are not running an EC2 instance, the runit-base repository is probably closer to what you want.

For kernel upgrades and cleaning obsole stuff, see the Simple Installer and the kernel module. NOTE: the kernel module is only of interest if you are compiling your own kernel, ignore it if you are on stock.

Generally on symlinks You are right, I am deliberately replacing some system scripts with symlinks. This is being done in the runit-init autorun script. Currently these are being replaced (symlinked):

These are symlinked to their runit compatible versions provided by the Simple Installer in the sin runit-init command. This installer is my attempt to ensure compatibility and smooth upgrade path from sysvinit to runit-init. Currently, I am not aware of any other upgrade method. The packages as provided by Debian/Devuan or other distros are not there yet, mostly they are missing the necessary ecosystem around runit required for PID1 operation. I understand that these symlinks are not pretty, but they keep the system stable. Updates don't break them, they are not overwritten. They also cannot be placed somewhere else, since they need to replace the original sysvinit commands.

I could use a prettier switching interface like update-alternatives, but that does not solve anything unless other init systems use the same facility. The best I can do is trying to keep the upgrade path from sysvinit to runit as smooth as possible. And don't break too much in the case you would want to switch back to sysvinit (currently you would have to do that manually).

cloux commented 5 years ago

I would like to discuss better solutions for runit system integration, I am still actively working on that.

Since it is not an AWS EC2 specific problem, I am closing the issue here. Please feel free to open an issue either for the runit-base or for the Simple Installer repository regarding the runit-init module.