All they did was change the XC_ALL build parameter to OFF [0] which happens to be the default in upstream's CMakeLists.txt [1]. If upstream thinks this functionality is so important maybe they should fix their defaults.
I think it's a bit unfortunate that users of this package may be confused why stuff stops working when they upgrade, but having the unsuffixed package match upstream defaults seems entirely reasonable otherwise.
> If upstream thinks this functionality is so important maybe they should fix their defaults.
> none of these features are plugins. All of them are built-in functionality that belong to the main product. If anything, we will reduce the number of such compile-time flags in the future, so these things cannot be disabled anymore.
That's certainly their prerogative, but I guess what I'm really trying to say is it's weird that they're so bent out of shape about a distro maintainer using a build option they added to their own code. Especially when said maintainer set it to the default they themselves set. If you were to download the source from github and follow the instructions in INSTALL.md which specify "Recommended CMake Build Parameters" you will end up with a binary with the exact same feature set as what the debian package now has.
>> none of these features are plugins.
I wasn't going to comment on this because it's a bit petty and is ultimately a boring semantic argument, but since you quoted it in a reply to me I will. Their CMakeLists.txt literally refers to these as plugins in the description of the XC_ALL param that was changed: "Build in all available plugins"
INSTALL.md [0] recommends passing -DWITH_XC_ALL in the Build Steps section.
This build option exists. If you're building from source and don't need any of the extra features, you can use it to get a leaner binary. But the Debian maintainer made this decision for everybody, removing important security features (such as browser integration and YubiKey support) from the main `keepassxc` package, which broke people's existing installations, and which means that people blindly running `sudo apt install keepassxc` will get an inferior, less secure product.
> INSTALL.md [0] recommends passing -DWITH_XC_ALL in the Build Steps section.
You're right, I missed it there. Silly me for assuming that all of the recommended CMake flags would be specified in the section titled "Recommended CMake Build Parameters"
At first I thought it should be the other way around. Keep the current keepassxc package and create a keepassxc-minimal. But seeing the build options it makes sense to have a keepassxc-full.
Only thing is this will annoy some people when they upgrade. But only when this reaches stable and then there will be notice in the upgrade documentation and apt-listchangea.
I think it's a bit unfortunate that users of this package may be confused why stuff stops working when they upgrade, but having the unsuffixed package match upstream defaults seems entirely reasonable otherwise.
[0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f... [1] https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...