System-specific configuration. This directory may or may not be read-only. Frequently, this directory is pre-populated with vendor-supplied configuration files, but applications should not make assumptions about this directory being fully populated or populated at all, and should fall back to defaults if configuration is missing.
Table 2. System package variable files locations
Directory
Purpose
/etc/package/
System-specific configuration for the package. It is recommended to default to safe fallbacks if this configuration is missing, if this is possible. Alternatively, a tmpfiles.d(5) fragment may be used to copy or symlink the necessary files and directories from /usr/share/factory/ during boot, via the “L” or “C” directives.
Vendor (Garuda) provided packages should install their inserted modifications to upstream (Archlinux) packages to /usr/when it is possible. Only when the specific packages are by their nature impossible to override settings, only then it is OK to install mods on /etc/.
This is a per-package/function consideration, so an investigation is required to find an existing way to apply modifications using /usr/ files. This is possible in most cases, because of systemd and tmpfiles and udev functionality.
If we decide to change this for Garuda packages, there should be exhausting discussion on “how to apply this on packaging”.
If we go this route, we may need some time, but IMHO it will save us (and users) from future problems.
Because this needs time, we can set a target (maybe next ISO release) and try to find the best ways to do it.
It isn’t easy as well. Changing this will have to deal with old settings files and seded modifications done by package hooks. Packaging will need some (a lot) of work, at least for confirmation before introducing changes.
They are all at Gitlab.
I am joking
Do you see now that this answer is not a good one? I was given this answer several times.
Mostly in the Performance/Power settings IIRC, but I don’t remember exactly.
I will try to gather them (again). I have to look into all PKGBUILDs of all Garuda apps.
If configs are provided by packages, wouldn’t the changes be applied automatically on update?
I will look into some more packages tomorrow as well and suggest changes.
AFAIK when you remove/uninstall a package with pacman, configuration is not removed unless you add the proper -n flag.
When it is updated, I don’t know the sequence of possible events in the case it is replaced by a new package with Replaces:, or what is the proper/best method if any.
I think, even if I RTFMs, it needs testing on a real system.
Also, in the case the user has modified the settings file, pacman behaves differently (adding a .pacnew). I don’t know if there is an option to activate a .pacsave, which I remember from somewhere.
The udev rules are read from the files located in the system rules directories /usr/lib/udev/rules.d and /usr/local/lib/udev/rules.d, the volatile runtime directory /run/udev/rules.d and the local administration directory /etc/udev/rules.d. All rules files are collectively sorted and processed in lexical order, regardless of the directories in which they live. However, files with identical filenames replace each other. Files in /etc/ have the highest priority, files in /run/ take precedence over files with the same name under /usr/. This can be used to override a system-supplied rules file with a local file if needed; a symlink in /etc/ with the same name as a rules file in /usr/lib/, pointing to /dev/null, disables the rules file entirely. Rule files must have the extension .rules; other extensions are ignored.
Doesn’t that just stop it from saving .pacsave files?
Is that what you want in this case? Would it not be better to let the package remove them and move them to a new location without writing pacsave files or am I missing the point of what you are trying to accomplish?
Maybe a misunderstanding of the change.(?)
AFAIK pacman creates pacsave for each Backup=(file) directive, if the file is changed from DB timestamp and exists in filesystem (and is being installed I suppose).
If the new package does not install the old file, I suppose it will not create pacsave (specially if the file is not modified). What I need to RTFM is if the new package has the same name and installs to a new target, whether it removes old target files, reading local DB info. Or, if the new package has different name and Replaces the old one (old name), whether it removes old package’s files on old target folder(s), reading local DB info.
I believe in both cases it will remove the files. In the case of replaces, it will remove the old package and replace it with new so it will uninstall all the files from the old package.
If nothing is currently set as backup in the old package, I don’t believe anything will be backed up in that transition.
This is how it is explained in Archwiki. All case studies are about having a backup() directive. In further thinking, we should have had a backup() directive for those (discussed here) files in the first place…
In any case, this kind of cases the new System Maintenance app was going to assist on clearing up and helping resolve, especially with systems that have a long time to be updated. We might keep it for a last resort, though . Or maybe we make @TNE happy, using the new toy?
After further reading (PKGBUILD) I am fairly (more) confident that there are clear solutions and they are at least two.
Raise each changing package to a new major version (1->2) and add
conflicts: packagename <=current/old version
provides:packagename (this may exist already)
Change packagename and add
replaces:old-packagename
Just a note: While having the old way packages installing setting files at /etc/, there is no backup() directive for the installed/provided files. This is not required with the new way of installation, which does not need such an option, because the user may install an overriding file at /etc/, which will still carry on working.
In fact, we could use this method, in addition to the above change, with double profit!!
Scratch the old proposal (not exactly) and here is a new one:
The proper way
In each current package that installs configuration files in /etc/ target, we can add the same file to the relevant /usr/ target directory, without the need to delete old/existing/modified(by the user) files. We also add a backup() directive for the /etc/ files in the PKGBUILD.
In this way
we have an original setting, available to reset to default or the user can decide to use the always better settings (if/when they change).
If/When a setting is changed, there will be a pacman message for a pacnew file, in the case a user has modified the /etc/ installed setting to customize/override it to specific needs.
If/When a setting is changed, there will not be any pacman message (no pacnew created) for cases of inexperienced user that did not know or change the file, or anyone that likes to have no messages
I have skimmed, will come back to this later today (it’s 02:30 here).
If the file is installed by a package then moving it is trivial - the new package will remove the old file and place it where the new file is.
If a packaged file has been manually changed, and it’s not in a backup array then nothing will change, or it is in a backup array it will be kept as a pacsave.
If the file is installed via a script (e.g. using a hook or install file, outside of pacman) then there’s no easy way of doing it, as the file may or may not be present.
There is a way of moving old scripted files into place using an install file (I did it for a Manjaro package back in the day) but it’s a hacky terrible solution as any files installed should be part of the package.
No, its not what I want - I just wanted to explain how to create .pacsaves as the topic came up
Thats generally also what my experience was.
I started altering PKGBUILDs now:
I don’t really see the benefit of adding the file in both locations - sure the user has a “backup” file with default content but wasn’t one point of this whole changes to have Arch provided defaults in case our /usr/ configs are not in place?
An example where its unclear to me whether moving to /usr/lib would be beneficial is the configuration of zram-generator: in this case, in /usr/lib/systemd it seems we got a lot of binaries and .service files. There are also very few .conf files but most of them are located in /etc/systemd. I think changing this might cause confusion as /etc/systemd is often used to control systemd settings (my personal experience)
A default config file may be located in /usr. This generator checks the following locations:
/run/systemd/zram-generator.conf
/etc/systemd/zram-generator.conf
/usr/local/lib/systemd/zram-generator.conf
/usr/lib/systemd/zram-generator.conf
… and the first file found in that list wins.
Maybe in this case, it would be better to create a drop-in in /etc/systemd - what do you think? Proposed change (man polkit expects configuration in /usr/share):
Don't know about others but for garuda-hooks it's better to move /etc/pacman.d/hooks to /usr/share/libalpm/hooks. As far as I know these hooks are not intended for users to tweak.
I think you have that logically backwards. Moving them to /usr is what allows people to override the hooks more easily. When the hook is in /usr, you can easily override it with your own copy in /etc. You should always let the user override hooks. For example, there are times when it is beneficial to temporarily inhibit certain hooks in system rescue scenarios.
. Or maybe we make 
