Plasma Vault in 5.11.0; wrong CryFS & fusermount.

Thanks Paul. I’d not seen that BR before, but i had read mumblings elsewhere [KDE on [i]reddit, i think] about deletion concerns. I agree that’s important in principle, but for me atm only very low priority in practice. Am happy to wait for 5.12.0.

Well, yes, which is why i asked my earlier question seeking advice on the best way for me to manage my repo list now pls.

I would still only install the file(s) needed and disable the repo (that’s why zypper in <some_URL/<some_rpm> can be sufficient) then wait for Tumbleweed to catch up and replace it when the updated package(s) arrive. Else there is a potential to pull in an unwanted package (hence the -vvv option on a dup), just easier to manage IMHO.

That’s absolutely my understanding too, based on my incremental learning in these fora from previous help by you & others. However, as i showed in my post:

At first, after getting Vault working & recovering from the crash], i thought it best to disable this repo, so as to avoid future possible headaches during later dups. However, trying an exploratory dup then gave this unpleasant output:

sudo zypper -vvv dup
[sudo] password for root: 
Verbosity: 3
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Initialising Target
Checking whether to refresh metadata for My_openSUSE_Repo
Checking whether to refresh metadata for Vivaldi
Checking whether to refresh metadata for Main Repository (NON-OSS)
Checking whether to refresh metadata for Main Repository (OSS)
Checking whether to refresh metadata for Main Update Repository
Checking whether to refresh metadata for Packman Repository
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
Force resolution: No
Computing upgrade...

Problem: problem with installed package fuse-2.9.7-80.4.x86_64
Solution 1: install fuse-2.9.5-2.2.x86_64 (with vendor change)
obs:// → openSUSE

Choose the above solution using ‘1’ or cancel using ‘c’ [1/c] (c): c

I re-enabled said repo, after which dup was happy… but am i setting myself up for some future headaches with this repo active? Would it be better to again disable it, then lock my Fuse version, then some time in the future when the new Fuse version lands in the standard repos, remove the lock & let dup then change it to the standard repo?

ie, disabling this new repo basically blocks any further dups [given that downgrading Fuse again is counter-productive]. Hence my contemplation of the possible safer(?) interim alternative of maybe] yes removing that repo BUT then also locking my Fuse version [so that i can keep doing my future [i]dups]?

To answer my own question: After successfully testing first in a VM, i’ve now done my workaround suggestion, for the interim [ie, until Fuse appears in the main repo], in both PC’s real TW:

  1. Disabled the FileSystems repo again.
  2. Locked my current Fuse version fuse-2.9.7-80.4.x86_64
    in YaST. 1. Confirmed that zypper dup’s
    are still happy, & don’t threaten to remove fuse-2.9.7-80.4.x86_64 & replace with the original main repo fuse-2.9.5-2.2.x86_64.

Update: Fuse 2.9.7 appeared in the main repos sometime over the past few days, so i have unlocked my one from the FileSystems repo & allowed YaST to change back to the main repos one. Plasma Vault continues to work well.