'zram-generator' incorrectly listed as hard dependency for 'garuda-common-settings'

inxi:

CPU: Dual Core Intel Core i5-6300HQ (-MCP-) speed: 2304 MHz Kernel: 5.13.9-zen1-1-zen x86_64 Up: 40m 
Mem: 1360.0/5936.0 MiB (22.9%) Storage: 127 GiB (5.3% used) Procs: 292 Shell: fish inxi: 3.3.06

I don't want to use ZRAM, but the 'zram-generator' package is listed as a hard dependency for the 'garuda-common-settings' package, and if I uninstall 'zram-generator' it also uninstalls a bunch of other Garuda customizations. I can override this temporarily by running 'pacman -Rdd zram-generator' to remove it without performing any dependency checks, but 'zram-generator' gets reinstalled automatically the next time I install updates so it's not a permanent solution.

It is possible that setting 'zram-generator' as a hard dependency for 'garuda-common-settings' was an ideological decision -- I've noticed people tend to be vehemently pro-ZRAM or anti-ZRAM -- but this dependency is factually incorrect, because Garuda runs just fine without ZRAM, just like any other desktop Linux distro with ZRAM installed by default (Fedora comes to mind). Please remove this dependency so people who don't want to use ZRAM don't have to uninstall it after every update cycle.

I am not an expert on this but garuda-common-settings is a package that includes many of things that garuda installs by default. In many cases, it does this by requiring the other packages in the same way a meta-package would. You could easily make the argument that there is nothing in garuda-common-settings that is required to run garuda linux. The argument that it is factually incorrect is silly. It is just an implementation decision like any other.

That being said, if you don't want zram there are lots of options available. You could change the config for zram-generator so it doesn't do anything. You could remove garuda-common-settings. You could also create a empty package that provides zram-generator which would satisfy the dependency without having to keep it installed.

8 Likes

I already tried removing 'garuda-common-settings'. That is not viable because it removes other customizations in the process. It's not just a shell-package that references a bunch of other packages, it has its own content too.

I also tried editing the config file for zram-generator. It gets overwritten when updates to the package are installed. So that is also not a permanent solution.

What I said is not silly. 'garuda-common-settings' does not actually require 'zram-generator' to work properly, therefore the dependency should not exist. 'zram-generator' can still be installed by default, but it should not be linked to another package that doesn't actually need it to function.

Yes, there are workarounds that I can use, and I am in fact using them. That does not obviate the point that the problem being worked-around should not exist in the first place. There is a false dependency that needs to be removed.

Open a terminal and type "sudo pamac remove zram-generator" and look at all the other packages that will be removed because of this false dependency, and you will have a better understanding of the problem.

That is caused by your pamac settings.

sudo pacman -Rc zram-generator
checking dependencies...

Packages (2) garuda-common-settings-2.0.3-1  zram-generator-0.3.2-1

Total Removed Size:  1.14 MiB

:: Do you want to remove these packages? [Y/n]
2 Likes

Have you tried

 pacman -Rdd zram-generator

Thats your opinion and I think you did not understand what @dalto was trying to say. We provide an oppiniated setup which also includes the usage of ZRAM. In fact, none of the requirements of garuda-common-settings is REALLY needed for the system to work.

Configuration files are present in /usr/lib and can therefore be overriden by placing another file in its respective location in /etc/.

3 Likes

Did you read my first post?

I don't know what your background is, but I've been a professional software developer for 15 years and I've been writing code on my own for 30. The way you are using dependencies is incorrect, and that is not a matter of opinion or personal preference. Dependencies have a specific purpose. If 'library_1' will crash or fail to compile without 'library_b', then a dependency exists, and the package manager should enforce that dependency to ensure 'library_a" compiles and runs successfully. If 'library_a' won't crash or fail to compile without 'library_b', then a dependency does not exist and the package manager should not enforce it.

'library_a' and 'library_b' can still be included together in the distribution by default if the developer recommends or prefers it, but the developer's opinion is not to be enforced by false dependencies. Doing that is bad practice.

I understand what you said
Actually we have discussed it making them optional

We will probably do it this way
Install them by default via iso explicitly
And not make them dependancy of common setting package.

And probably give option in assistant

The reason we did it this way was we constantly make changes to defaults as and when we discover if our setting are good or not.
And we wanted to ship them to all existing users

Currently we have mostly figured it out.

5 Likes

Thanks for the reply. My only intention with this thread was to submit a bug report. I wasn't trying to start an argument.

1 Like

I dont like your way of proving your point - "I have experience so your opinion is invalid" is never a good way to make someone change something.
Dependencies can of course be used like this but what about metapackages then? They are all redundant and "wrong"?
Read my post again, its easy to override our distro defaults shipped in common-settings, especially for someone as knowledgable as you :wink:

5 Likes

Does not look like from where i'm sitting. More like looking to find a fault with out considering others lol.
Like why do you ship KDE as I don't use it.

That is one way to use dependencies but it isn't the only way or the correct way.

Arch-based distros commonly make use of metapackages or pseudo-metapackages. The way those packages work is that they use dependencies to forcibly install a group of packages together.

This strategy has pros and cons.

The pros are that it makes it so that when changes in the package occur, it pushes those changes out to existing installs. In a distro like Garuda, where many users don't get involved in the details and want things done automatically, that is a pretty big advantage.

Arguably, that same pro can be considered a con depending on the circumstance. A further con is that, as you discovered, it makes removing part of the package somewhat tricky.

The point is that it is an implementation decision that isn't right or wrong in an absolute sense.

For me, personally, I am not a fan of meta-like packages unless they are highly targeted. That being said, that is my preference, not a statement or absolute truth.

There are plenty of packages like that in the Arch repos as well.

7 Likes

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