>
If the files/config (I know the author argues they aren't config files) are truely immutable why would the system upgrade command modify them?You are confusing the two different scenarios that you need to distinguish.
The first scenario is when a config file is simply a part of a package, managed by the package manager. In any reasonable package manager, if you ever edited a config file manually under /etc, the package manager will never attempt to update it automatically. For example, apt-get will ask you whether you need to preserve the old file, use the new file, or diff-and-edit it manually. This is the reason why the author suggests to move rc.d from /etc to /libexec, because every time you upgrade your system, the package manager will ask you to diff-and-update some random runscripts that you've never written.
The author's point here is that the rc files do not behave like config files, they are closer to programs or executables, the package manager should be able to update them when a new version in installed without annoying the user, just like any other binaries.
---
The second scenario is when a config file is managed by the init system, a script, or a daemon in the system. For example, /boot/grub.cfg is managed by update-grub & os-prober, and ideally one should never edit the file manually.
In this scenario, it's completely off-topic and irrelevant to the original topic of whether rc.d should be treated as libexec, but here's my opinion anyway...
> I was amazed at how much effort I had to spend fighting the OS to just say "Stop managing this file, do not load this file, I am going to manage it"
Never attempt to fight with the system in a brute force manner - edit this file, later the file is edited back, edit again, edit back, and finally "chattr +i" the file, I never understand this mentality. Using "chattr +i" is almost never the correct solution.
All you need to do is politely tell your intention to the daemon in charge, spending 30 minutes (or each time after a system upgrade) to fight with it, can easily save your 5 minutes to read the documentation.
> for an extra challenge try setup /etc/resolv.conf using unbound as a stub resolver.
If you read the documentation, you'll sometimes find your needs are already supported, and managing it manually is not needed in the first place. For example, NetworkManager already comes with builtin, automatic support of a stub resolver. Not only that, it supports both dnsmasq and unbound, and even has extra logic to help you updating the DNS when you're connected to a VPN. All of these features are here to make one's work easier.
Yet one still chooses to fight with the system in the most brute force way such as "chattr +i", at the very least you can turn it off smoothly and it'll never bother you again.
For example,
$ man NetworkManager.conf
> dns
> Set the DNS processing mode.
> default: NetworkManager will update /etc/resolv.conf to reflect the nameservers provided by currently active connections.
> dnsmasq: NetworkManager will run dnsmasq as a local caching nameserver, using "Conditional Forwarding" if you are connected to a VPN, and then update resolv.conf to point to the local nameserver. It is possible to pass custom options to the dnsmasq instance by adding them to files in the "/etc/NetworkManager/dnsmasq.d/" directory. Note that when multiple upstream servers are available, dnsmasq will initially contact them in parallel and then use the fastest to respond, probing again other servers after some time. This behavior can be modified passing the 'all-servers' or 'strict-order' options to dnsmasq (see the manual page for more details).
> systemd-resolved: NetworkManager will push the DNS configuration to systemd-resolved
> unbound: NetworkManager will talk to unbound and dnssec-triggerd, using "Conditional Forwarding" with DNSSEC support. /etc/resolv.conf will be managed by dnssec-trigger daemon.
> none: NetworkManager will not modify resolv.conf. This implies rc-manager unmanaged.
$ man systemd-networked
> by one of the .network files will be ignored. It is also possible to
> explicitly tell systemd-networkd to ignore a link by using
> Unmanaged=yes option, see systemd.network(5).
I guess one reason that everyone's fighting with the system is not realizing the official way of telling one's intention to the system. Perhaps everyone should learn the way GRUB warns its user.
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
Perhaps someone should contribute a patch to NetworkManager to add a similar warning.
# DO NOT EDIT THIS FILE. This file is currently under the management
# of NetworkManager. It's automatically generated according to the
# DNS configuration of the current network connection in NetworkManager.
# Any change to this file will be overwritten.
#
# If you are trying to change your DNS resolver per connection, use "nmtui", "nmcli",
# or alternatively, edit "/etc/NetworkManager/system-connections/".
#
# To stop NetworkManager from managing it altogether, edit
# /etc/NetworkManager.conf, set the following and
# restart NetworkManager, before you edit /etc/resolve.conf.
#
# [main]
# dns=none
#
# If you are trying to set up a stub DNS resolver, it's recommended to
# NetworkManager's builtin support. Set "dns=dnsmasq" or "dns=unbound"
#
# See "man 5 NetworkManager.conf" for more details.