I think you'd have to actually ask the users about that. Not make assumptions based on some loud people on a Mastodon thread. What the user is given here is a choice.
Well no, what the user is actually being given is a completely different application than the original one they downloaded, which is now increasing the maintenance burden upstream because THEY are they one getting all the bug reports because Debian decided to swap the packages out from underneath their users:
Users should ideally report bugs to their distribution, not to upstream. The distribution package maintainer then does triage to determine if the issue is specific to the distribution package or should be forwarded upstream.
That's how it used to be in the past (and still is for enterprise distros because you might as well use the support contract you paid for). But lately users have gotten more savvy about talking to upstream directly, especially since more and more upstreams are now on easy-to-use websites like GitHub instead of mailing lists. That's still fine if users do their own diligence to ensure the issue is with upstream and not with the distribution package, but alas they don't all do that, leading to these spurious reports.
I thought from reading the bug report is that they only changed the default of a supported cmake build flag. I think that a keepass-nonet would have be a wiser choice, but I do not blame Debian people to be opinionated towards the more secure choice.
vim-nox is pretty much full-featured vim without x11 stuff.
Do you have a non-trivial .vimrc/.vim directory?
Would you be accepting of the maintainer disabling a bunch of features and pushing those changes out under the main vim-nox package such that it breaks your existing install? Would it be reasonable to expect you as the end user to figure out what has happened and that you need to uninstall vim-nox and and install vim-nox-full?
But vim-nox is a separate package with a clear name saying that it's got X removed; I don't think this would be nearly as controversial if they'd shipped a keepassxc-nonetwork package.
Users should be asked if they actually wanted the features in the existing package after all? Why shouldn't users have been asked before changing the existing package?
I'm one of those users. If I'm loud, does that mean my opinion doesn't count anymore?
It never counted. You can suggest or advise, but you never had the power to tell Debian what to do. Being loud will not change that, no. You'll have to resort to persuasion.
It is marked as 'Priority: standard' thus installed as part of the standard Debian installation and shows only NEWS entries by default without needing further configuration.
You definitely see it for several packages during dist-upgrades. Same in sid/testing except it can be any time though it's a rare event.
In case apt/dpkg is configured to ignore those, information still resides in /usr/share/doc/<pkg>
it'll also be put in the release notes when the next major Debian version is released.
I mean, distributions have already figured these things out 20 years ago, but I guess
users nowadays expect these to be announced in Twitter or a pinned Github issue or something :-<
But they already had a choice, since the removed options were disabled by default.
This really just breaks core functionality that exists and is expected by real users, under the guise of unnamed security risks...theres plenty of disabled options in Linux that are "potential" risks, so its a silly choice.
Let's say that I had the previous version of keepassxc installed and used a Yubikey to protect it. Now when the distro updates, through no actions of my own, I will be locked out of my password DB because the Yubikey extension is no longer compiled in to the version of KeePassXC the distro is shipping under the original name. Yes, this breaks core functionality. How is this a good thing?
Choice was already made when they installed it with xyz features available.
If it was so important they never should have packaged it in the first place. -Minimal option is the obvious reasonable choice, unless trying to be an arse to make a point, since you're changing a users choice after the fact.
Are we going to stop compiling sshd with plaintext pw options and root login, and suddenly?
If a user has an option enabled you don't like anymore, notify them, don't blindly remove functionality and say "your fault for not reading the changelogs".
Frankly the security claims ring more of hyperbole than anything
> If a user has an option enabled you don't like anymore, notify them, don't blindly remove functionality and say "your fault for not reading the changelogs".
apt shows the NEWS file during update when there's a change. These users not only have chosen to actively ignore the warning that has been shown to them by default, they've also chosen to directly go to upstream to complain instead of first their distributions channels.
