Potentially stupid question about user config changes

So this is less of a question about the tech and more of a...what do other people do? thing. So I've used arch and arch based distributions for quite some time, but have never used anything with constantly updated settings packages. I'm on the dr460nized edition so I've got the garuda-dr460nized package.

My question sorta revolves around when that gets updated and user config changes get made. I'd like to stay on top of that in case of anything major changing however, there's a couple of layout tweaks (turn off borderless windows, size tweaks to the top and bottom bar, etc) that I make (which aren't a big deal) and pinned applications on my bottom dock which get reset whenever the configs get reapplied through Garuda Assistant.

Guess I'm curious:
a) how often do other users re-apply the user configs? I assume eventually something will come along in a package update that will break the config and need to be updated
b) You have any advice for quickly re-applying pinned app settings?

The closest thing I've been able to figure out is to save out that section of the latte-dock config once I have it how I want it and then copy it back into the config file after the update happens, but I'm curious if there's a better way and I'm just being dumb here :wink:

Thanks for the work that goes into this distribution, by the way. Pretty sure this is exactly what I've been looking for.

For the most part, I take the 'if it isn't broken, don't fix it' approach. Ie, I don't reapply changing configurations, which seem to me to mostly be very trivial (often just commented out sections).
If I had something misbehaving, I'd save my custom config (if any) and reapply the defaults and test.


You may try this applet


Oooh, good call. I must have missed that one. I'm used to GNOME, switched to Plasma with the latest 5.21 release. Appreciate the pointer!

1 Like

So to give an idea the update process of user configs:
There are some editions which do not change configurations often while others do. I recently included instructions on how to update to newer versions in some packages to make getting on newer configs (if that is desired) easy - many people dont know about this so I thought it might be a good idea.
That being said, you dont have to update the configs. If you found a setup which works well for you and dont like changes its completely fine to just stay with the already working one. Sometimes there are bugfixes, sometimes new features. You can easily track what exactly changed by looking at the GitLab commit log, lets take dr460nized as example:

The following commit for example is a bugfix for a blurry start menu icon, which might be worth getting to save the hassle of doing it manually.

In the end its your decision, updating the configs has been made optional for a reason. :slight_smile:


Awesome, thanks for the explanation. That's really helpful in putting my mind at ease as to the intended methodology.

Also thanks again for all the work you put into this, love the setup.

/etx/skel/* is supposed to be used only for when a new user is created.
All other usage should be done only by hand-picking specific files, or merging like pacdiff type.

My suggestion (to Garuda mods) is to adjust new config introduction with Welcome tools, by case. It needs a per case selection, when pulling new configs into user $HOME.
IDK if it's understandable, but hey... I'm Greek :rofl:


While there is the plasma widget @petsam kindly linked, you can also automate most anything you want by writing a service yourself. A little more effort to learn, but once you learn how to write services you will truly be the master of your system and no longer be beholden to systemd.


IDK if this makes any sense, but is it possible for these config changes to be identified as .pacnew files? That way we see they have arrived, and all of us conscientious users will pacdiff and merge if appropriate...

Right? :grin:

1 Like

I would definitely love an option for a config file merge, rather than a straight overwrite.

But I can also understand that the dev team might not want to deal with somebody partial merging something and breaking everything if they don't know what it is they're doing :wink:

So I can see both sides of that coin.


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.