Follow systemd requirements

[fredleb]

About https://github.com/sibradzic/amdgpu-clocks#making-the-custom-power-states-persist: Users should not modify files in /lib/systemd/system/ as these are normally managed by their distribution/package manager. This would cause problems every time systemd is upgraded.

Users should place the service files in /etc/systemd/system/

See https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/chap-managing_services_with_systemd#sect-Managing_Services_with_systemd-Unit_Files

See https://wiki.archlinux.org/title/systemd#Writing_unit_files

[sibradzic]

hi @fredleb , thanks for the comment! I am pretty clueless when it comes to systemd, please feel free to submit a PR against README if you feel confident that placing services in /etc instead of /lib is the best-practice approach.

[berniyh]

hi @fredleb , thanks for the comment! I am pretty clueless when it comes to systemd, please feel free to submit a PR against README if you feel confident that lacing services in /etc instead of /lib is the best-practice approach.

Actually that has nothing to do with systemd as such. Users should not modify files in /usr/lib or /lib (the latter is usually a symlink to the former these days), period. It's very bad practice. That's why programs either provide mechanisms to load files from /etc and /usr/lib, or only from /etc. Thankfully, most programs these days choose the more flexible variant, like systemd does. The main reason for this change is that files in /usr may be overwritten by the package manager, thus your changes can be lost, while in /etc they are retained and have to be merged manually or semi-automatically. The flexible approach has the advantage that users don't have to merge config files they didn't change (and that now sit in /usr, unless they were overruled by something in /etc).

[sibradzic]

Yeah, yeah. Well, you really seem to passionate about this, I'd love to check your PR that updates the README ;)