Removing kwallet from system closure / as dependency of nextcloud-client

Help
1

I could use some help in investigating a problem. I’m not well versed with nixpkgs intricacies, so maybe someone here has an idea.

Since 25.05 my system has kwallet installed, seemingly via nextcloud-client.

$> nix why-depends --all .#melissa nixpkgs#kdePackages.kwallet

/nix/store/y40wlcvf3mxzq5j3v1a30y01gcbpannv-nixos-system-melissa-eisfunke-6977a94d9-dirty-25.05.20250612.fd48718
└───/nix/store/d39qg5j52rjnbhh832541nrs437ix4k2-etc
    ├───/nix/store/hfpii6xnbzx4s26mm2jhs001db49h151-user-environment
    │   └───/nix/store/dh09jrhxs590kxh3nszsdkxx4b5w6pw8-home-manager-path
    │       ├───/nix/store/by5z7x5gmisc3r11hq3n2ja5anrdz1lv-kwallet-6.14.0
    │       ├───/nix/store/hfylsf8c1cs4x9l1yvvlrmlhrcgdbnkv-kio-6.14.0
    │       │   └───/nix/store/by5z7x5gmisc3r11hq3n2ja5anrdz1lv-kwallet-6.14.0
    │       └───/nix/store/v0dqs88n707j46c6nlypxcvr5bp5ysff-nextcloud-client-3.16.4
    │           ├───/nix/store/by5z7x5gmisc3r11hq3n2ja5anrdz1lv-kwallet-6.14.0
    │           └───/nix/store/hfylsf8c1cs4x9l1yvvlrmlhrcgdbnkv-kio-6.14.0
    └───/nix/store/6xm8h1qyv7z6nrzjkqckj48jq9x9szg6-system-units
        └───/nix/store/x7vj13711szl23i2y43qly3ajprcisb4-unit-home-manager-eisfunke.service
            └───/nix/store/w3njhwqpwrjm2jdakf3c5yg4s6q5brmq-home-manager-generation
                ├───/nix/store/dh09jrhxs590kxh3nszsdkxx4b5w6pw8-home-manager-path
                └───/nix/store/1660yf3xq30s1phazgdhkcag0b8xiwaz-home-manager-files
                    └───/nix/store/c5y3i6qwbbr8h1624x5xcjz2mszlyz5d-hm_fontconfigconf.d10hmfonts.conf
                        └───/nix/store/dh09jrhxs590kxh3nszsdkxx4b5w6pw8-home-manager-path

I’m not entirely sure that it wasn’t included before 25.05, but since that update some applications started trying to use/launch kwallet, which is why I noticed it being installed.

I don’t want kwallet, as I’m already using gnome-keyring and I don’t want applications to attempt to use the other secret manager. I don’t think it makes much sense for nextcloud-client to depend directly on kwallet anyway, because it uses gnome-keyring just fine. Installing a secret manager should be task of the overarching system, not a direct dependency of the package, I’d say.

So I tried to find out why it’s there and how to get rid of it. It looks like it’s pulled in via kio?

$> nix why-depends --all nixpkgs#nextcloud-client nixpkgs#kdePackages.kwallet

/nix/store/v0dqs88n707j46c6nlypxcvr5bp5ysff-nextcloud-client-3.16.4
├───/nix/store/by5z7x5gmisc3r11hq3n2ja5anrdz1lv-kwallet-6.14.0
└───/nix/store/hfylsf8c1cs4x9l1yvvlrmlhrcgdbnkv-kio-6.14.0
    └───/nix/store/by5z7x5gmisc3r11hq3n2ja5anrdz1lv-kwallet-6.14.0

Which makes sense to me, because the nextcloud-client package.nix pulls in kdePackages.kio.

I fail to understand why kio depends on kwallet though. Its default.nix doesn’t reference kwallet or even kdePackages at all. It uses mkKdeDerivation, which seems to be defined here, but that doesn’t reference kdePackages or kwallet either.

What am I missing? Where does the kwallet depenency come from?

(Btw, getting rid of it in my system closure by overriding kwallet with null or a placeholder didn’t work, presumably because it’s pulled in through kio? And I can’t override the kwallet input of kio because it doesn’t have one…)

2 Likes
2

(saw your post on mastodon)

I think the correc file for kio is this one which does reference kwallet. No idea why there are 2 kios in the tree though.

1 Like
3

One (development/libraries/kde-frameworks) is for KDE 5, the other (kde/frameworks) is for KDE 6.

Compare libsForQt5.kio.meta.position and kdePackages.kio.meta.position for confirmation.

So OP has the right file. But the wiki has a section on what you need to do to customize KDE packages; I expect adapting that first code listing by replacing the whole somepackage = ... attribute with kwallet = null; will do the trick for you (this should prevent all KDE packages from taking a dependency on kwallet, not just kio).

(Note that what is being listed there is an overlay, so if you aren’t familiar with what to do with an overlay, read this.)

1 Like
4

Thanks for the explanation! But how OP ended with kwallet in the closure of kio then?

1 Like
5

Thanks for the replies!

@rhendric I actually tried overriding kdePackages.kwallet in an overlay before posting. In my case with a writeText placeholder package instead of null and it didn’t work, I still had the original kwallet package. I hadn’t heard of overrideScope, I just overwrote the kwallet package, I think this lead to kio still using the kwallet from the kdePackages from before the overlay. overrideScope looks like it could fix that.

However, I didn’t try this, because I found another solution thanks to a reply on Mastodon. I now override kio for nextcloud-client and add an excludeDependencies argument to mkKdeDerivation to keep kwallet out. See here in my config: feat: remove kwallet dependency of nextcloud-client (ede4084a) · Commits · Configuration / NixOS · GitLab
Or see my nixpkgs fork how it would work there: kdePackages.kio: remove kwallet dependency · Eisfunke/nixpkgs@dd5d038 · GitHub

By the way, I wasn’t able to find the place that actually pulls in kwallet for kio because the dependencies for mkKdeDerivation are a bit hidden away in a generated file named dependencies.json, which is read by mkKdeDerivation. The excludeDependencies arg mentioned above allows to manually filter out some of these dependencies in the mkKdeDerivation call. Thanks to Hemera on Mastodon who explained this!

Because I still think it’s bad to have these packages depend on kwallet, I opened an issue to discuss removing it in upstream: kdePackages.kio (and more): kwallet dependency, should it be excluded? · Issue #416527 · NixOS/nixpkgs · GitHub

1 Like