keepass: install from setup package
Closes #5540
- [x] I have read the Contributing Guide.
This changes the keepass manifest to use the setup EXE rather than the portable ZIP. The reason for switching is that the setup EXE includes a default KeePass.config.xml that tells Keepass to prefer the user configuration, so that it does not try to save settings into the local/installation directory but rather to %APPDATA%/KeePass normally.
This sidesteps the issue with file permissions when pretend-persisting the local config from a global installation. Since this changes where the config should live this may be controversial so I would like to get comments and will mark it as draft for now.
All changes look good.
Wait for review from human collaborators.
keepass
- [x] Description
- [x] License
- [x] Hashes
- [x] Checkver
- [x] Autoupdate
/verify
All changes look good.
Wait for review from human collaborators.
keepass
- [x] Description
- [x] License
- [x] Hashes
- [x] Checkver
- [x] Autoupdate
/verify
All changes look good.
Wait for review from human collaborators.
keepass
- [x] Description
- [x] License
- [x] Hashes
- [x] Checkver
- [x] Autoupdate
Unfortunately this does cause problems for anyone who wasn't already storing configuration in a user profile, and it also completely screws up using the KeePass.config.enforced.xml config file. I'm still trying to untangle the mess at the moment.
I get trying to sidestep potential issues, but with this step what exactly is the point of using scoop to manage keepass instead of winget? At least for me it's going to be easier to just switch to winget for keepass at this point.
Awful change for me. Backing up whole persist folder much more convenient than separate folders in app data. As for the file permissions, there were never any problems. IMHO if app provides easy way to be portable with scoop (you transfer persist folder and install app, that's it), this should be used.
Thank you for the feedback.
I get trying to sidestep potential issues, but with this step what exactly is the point of using scoop to manage keepass instead of winget?
As for the file permissions, there were never any problems.
Keepass did not work in a global installation because it did not have permission to write settings to the config file which was actually in the installation path and not in the persistence path. It only used persistence as a backup on update, uninstall, or reinstall, this is the "pretend-persisting" that I mentioned.
Scoop can be used as a plugin manager for Keepass plugins. I found it desirable for security reasons to do a global install for Keepass and its plugins, rather than install to home directory or manually manage plugins.
Keepass did not work in a global installation because it did not have permission to write settings to the config file which was actually in the installation path and not in the persistence path. It only used persistence as a backup on update, uninstall, or reinstall, this is the "pretend-persisting" that I mentioned.
Scoop can be used as a plugin manager for Keepass plugins. I found it desirable for security reasons to do a global install for Keepass and its plugins, rather than install to home directory or manually manage plugins.
My suggestion is to consider the https://github.com/ScoopInstaller/Nonportable bucket. Create a keepass-np package there and, please, don't break the keepass package.
Edited in 06 mar 2025: From contributing guide, Portable configuration is highly preferred (by using persist)..
I agree with @juliomaranhao. Especially with all the other package managers out there if you really want a "global" install then use another package manager (or use the scoop nonportable bucket). Scoop was really designed around local profile installs anyway. The global package handling was always a bit of a bad fit for scoop IMO.
Clearly this was not a popular change. I can support reverting it if that is the consensus. Please note:
- Users will suddenly have Keepass targeting a different config, again.
- The issue closed by this change will need a different solution, we can consider adding an alternative "non-portable" manifest as suggested.
- Plugins from scoop will not work with an alternative manifest without reworking or duplicating the plugin manifests.
- The bigger issue is that scoop's support for persisting files is broken, see e.g. https://github.com/ScoopInstaller/Scoop/pull/3212
- If persistence was not broken then both use cases would just work by persisting the config file, but this does not work because the link gets broken and overwritten locally with a new file: https://github.com/wickles/scoop-extras/commit/fae19e5c13a2fa4f053aa48511d6c061412a8741