What I meant by that was users usually don't touch /usr/, unlike they do with /etc/, so I think anything that has no purpose of user's manual intervention should go to /usr/.
2 Likes
I think I explained the benefits, but maybe not well enough:
When the package introduces a changed content, because we have a better idea, as time may/will bring in something new/better, pacman upgrading will raise the change with a message for a new pacnew file (provided that we use a backup() directive for the file), which would not appear if we don’t have the (same as /usr/lib/<file>) file in /etc/<file> (backup files are only in /etc/).
An advanced user, or in case a specific system requires a different method/file than what we provide (as default), will not have a headache reapplying local admin changes after each package update.
In the latter case, if the user is not so well knowledgeable, doing a bad/wrong modification, will always have the default setting in /usr/ to revert to, without web searching.
I totally agree! This is the recommended method with systemd. Local admin will always have the option to override, either using systemctl edit method, adding an override.conf default file, or using /etc/ with the same file name. Thus, our drop-ins should have a proper file name, because it has some role (lexicographic order).
For better understanding we need to RTFM man systemd.unit
Part of.
In addition to /etc/systemd/system, the drop-in “.d/” directories for system services can be placed in /usr/lib/systemd/system or /run/systemd/system directories. Drop-in files
in /etc/ take precedence over those in /run/ which in turn take precedence over those in /usr/lib/. Drop-in files under any of these directories take precedence over unit files
wherever located. Multiple drop-in files with different names are applied in lexicographic order, regardless of which of the directories they reside in.
3 Likes
I think we are talking about a very specific situation here. A one-time move of package config from /etc to /usr. Once that is done, the package shouldn’t care about what is in /etc/ either way. If the user puts overrides in /etc, that is their choice. Am I missing something?
The conversation has gotten complicated so I am not sure that I fully understand what we are referring to at this point but I would say that the distro should not use drop-ins in /etc/ unless it is unavoidable. The user can use drop-ins to override the distro’s settings that way. If the distro uses drop-ins in /etc, you will need to then add those to the backup array and the user will need to deal with .pacnew files. If the distro puts it’s files in a system location, this is avoided completely.
Of course, there are some situations where it is unavoidable, such as when Garuda is overriding something from an Arch package and you don’t want to repackage it and maintain your own version.
2 Likes
I didn't understand why garuda-icons needs (empty) /etc 
1 Like
No. It’s OK. I was talking about a different approach, nothing more. You are right and I agree with all in this post.
We can see how it will go. I am sure nothing is wrong or bad in all said.
1 Like
Thats exactly why I was not sure if having things in /etc/ and /usr/lib would be a good idea. To me, not having stuff in /etc/ also means configuration files would not have to be .pacsaved and reverted - a few steps less required for system maintenance after a package upgrade.
It was about the zram-generator configuration currently provided as /etc/systemd/zram-generator.conf.
It doesn’t. Prior to adopting non-git PKGBUILDs almost every package would have this in package(). Seems I forgot improving this one back then 
Edit: here you go
https://gitlab.com/garuda-linux/packages/stable-pkgbuilds/garuda-icons/-/commit/3fbbafa5466b0445c6ff6943c847e75904e0386d
2 Likes
This also means that we already have backup() for all files provided by packages in /etc/? Have we?
Why is there a need to install this in /etc/ instead of /usr/lib/? Is it from the developer?
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 # <<---
3 Likes
You are right, changed.
2 Likes
For garuda-common-settings:
Though this should technically work, logically I don’t suggest using /usr/lib/ for these config files. /usr/lib/ is mainly intended for binary dependencies i.e. files like .so files.
/ usr/lib/
Static, private vendor data that is compatible with all architectures (though not necessarily architecture-independent). Note that this includes internal executables or other binaries that are not regularly invoked from a shell.
/usr/lib
Object libraries, including dynamic libraries, plus some executables which usually are not invoked directly. More complicated programs may have whole subdirectories there.
So garuda-common-settings is itself not an application but settings for the system. These configs are actually not libraries of any app, i.e. system can run without them (nothing actually requires them to run). So even if it works here, better to have them in /etc/ to fit according to the purposes. And also these files are:
Why?
- zram-generator.conf: For example, zstd compression method is not compulsory, user can remove compression, etc. according to their needs and the change should persist.
- udev/rules.d: For example, not everyone use SSD so not everyone needs NVMe, so these rules are system-specific.
- 99-sysctl-garuda.conf: For example, hiding kernel messages is not a must for Garuda and if one choses not to hide, the change should persist.
1 Like
I still feel like you are thinking of this backwards. By putting the distro files in /usr, that allows the user files in /etc to not be overwritten by package changes. If you put the distro versions of the files in /etc, now it gets harder for the user to manage because either the changes get overwritten every time the package updates or the files are added to a backup array causing the user to have to manually merge the changes.
It is becoming increasingly common for the distro config files to live outside of /etc and only have the user overrided files live in /etc. That is how systemd units work, alpm hooks, kernel-install files, etc, etc, etc.
There is actually increasing amounts of scripts and non-binary files going into /usr/lib on modern systems.
3 Likes
OK, I got your point.
Yes, I agree. But, they are all not system-specific, they are either distro- or app-specific.
Some examples:
File: /usr/lib/systemd/resolv.conf # This file belongs to man:systemd-resolved(8). Do not edit.
File: /usr/lib/sysctl.d/50-coredump.conf # This file is part of systemd.
File: /usr/lib/sysctl.d/50-pid-max.conf # This file is part of systemd.
File: /usr/lib/udev/rules.d/10-dm.rules # Copyright (C) 2009 Red Hat, Inc. All rights reserved. # # This file is part of LVM2.
So they are part of a package (in other words, they are needed by their respective binaries as they are) and users should not edit them. They are NOT system-specific. But this is not the case of garuda-common-settings, as I explained in “Why?” above, since those configs are more likely system-specific, so they better fit in /etc/.
1 Like
As currently I'm running live-ISO, what I can see is only garuda-hooks and garuda-tools-base-git are fine targetting /usr/ instead of /etc/, because:
For garuda-hooks: It's not intended to let users tweak os-release.hook, os-prober.hook, etc. (even if they can 
), so it's disrto-specific, NOT host-specific, so it's fine in /usr/.
And, these are the apps owning /etc/ unnecessarily for nothing inside:
2 Likes
Thanks for the list, will take of this later! 
Edit: done 
2 Likes
Every single one of those examples that you listed above are default values that can be overridden in /etc. That is the entire point. When it is possible, nobody should be editing the files that are installed by garuda-common-settings, they should be putting their own versions in /etc that override them.
Said differently, the files in the package garuda-common-settings are also not system specific. They are the defaults applied by the distro.
4 Likes
Yes, got it. Actually I was talking about editing those files, not creating duplicate copies in /etc/.
This is how I am able to analyze, I maybe wrong here and if so please correct me…
Even /etc/paru.conf is applied by the vendor themselves by default. But that doesn’t mean that it should be in /usr/lib. The vendor could say “copy and paste in /etc/ to override”, but they didn’t, because they don’t expect keeping it static. Same applies to pacman.conf too, it is originally in /etc/ and is not expected to be static.
OK. I think this is where I’m wrong. Got it. I was thinking this is as same as fstab and all.
As I know technically it shouldn’t matter actually, unless some advanced user prefer to have custom configurations.
2 Likes
This is for a different reason than other system settings/configuration and is (as I understand and agree) for keeping pacman.conf a single point of configuration, that is backed up when it upgrades, so a clear message is shown in pacman.log for gaining admin’s attention.
To better educate and understand the discussion topic, do study upstream filesystem PKGBUILD. You "ll see some basic config files installed at both /etc/ and /usr/share/factory/etc/. In this perspective, garuda could introduce its Garuda-brand-system-modifications installing them in both /etc/ and /usr/share/garuda/etc/ . You"ll also see the files that are being backud up with backup() array.
3 Likes
Would you agree with the current implementation of garuda-common-settings for now? I don’t see a reason to do backup() right now as previously all changes done to those configurations would have been overwritten by an update anyways & the new location allows people to override using /etc/
Once we have some application requiring system wide configuration it would be good a good time to implement backup(), thats where I agree with you. 
1 Like
A development build with the latest commits of garuda-common-settings is available as garuda-common-settings-git. Please test and report back.
2 Likes