[jeffalyanak]

I think the solution suggested by drawks seems clearly the correct choice:

> I think the proper solution would probably be to package both a "-full" and "-minimal" version of the software and utilize Debian package meta-data fields to define a Conflicts relationship between the packages and tag them also both with a Provides for keepassxc and also add a tag Replaces: keepassxc to the -full build so that during a package upgrade an existing user would be provided the version that continues to provide the features of the package which is being upgraded/replaced while new users can choose for themselves which of the versions they'd like to install

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

Why would this _not_ be the obvious choice?

[rfoo]

Because maintainers have an opinion and explicitly wanted to change the default.

[GorsyGentle]

Perhaps, and that's not unreasonable in and of itself. But to do so in such a user-hostile manner? That's a bit over the top. A new minimal package, advertising it, and only then eventually making it the default would have been far, far more effective.

If an engineer of mine pulled this on our user-base I'd have them reverting it in a heartbeat regardless of the technical merit. They already failed just in how they executed this and have burned good will, the technical merits no longer matter. Once you've lost the faith and trust of the user, it's over.

The original request[0] was more or less simply a user asking for the networking to be removed, and follow-up to just have a -nonetwork variation. Instead, we have comments from the debian maintainer:

The OP report: > Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks.

The debian package description[1]: > See keepassxc-full if you absolutely need those.

The PR[2] > Feature creep like SSH agent support, browser integration, Freedesktop.org secret storage, KeeShare pose undue risks for most users.

Each one of these sends a message. And it was entirely avoidable with a bit of grace and kindness to the existing userbase.

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529

[1]: https://packages.debian.org/sid/keepassxc

[2]: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...

[rfoo]

Yeah, I agree with you. I'm joking that KeePassXC developers should make parsing .kdbx an optional feature (that's an attack surface by itself for sure!) and see whether Debian package maintainer enable it or not.

[kasabali]

> user-hostile manner

This isn't user hostile.

You know what'd be user hostile? Removing the functionality and not providing the -full package alongside.

[LightFog]

It is.

The software has been broken - the UI wasn’t designed with those toggles in mind so now users suddenly have non functioning features presented to the in the UI.

The argument the all users should be keeping up to speed on NEWS - especially in the stable channels this will end up in - to explain why their UX is suddenly broken is not exactly ‘user friendly’.

[kasabali]

> all users should be keeping up to speed on NEWS

They don't need to, it is shown to them during apt-get upgrade

> especially in the stable channels

This is in testing/unstable. Stable users aren't and won't be affected until until the next major Debian version is released and the users decides to do the upgrade.

[jeffalyanak]

That does allow you to change the default for users installing the packages and while ensuring that users who already have it installed don't lose functionality during an upgrade.

[Liskni_si]

It not only _is_ the obvious choice, it is _exactly_ what has actually happened in Debian: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...

The original post is just a badly written clickbait. Nothing was removed, it was just moved to the keepassxc-full package.

[jeffalyanak]

I don't believe you're correct. It seems like the option that Debian decided on _will_ remove those features for users who are upgrading a package.

Users who already have the keypassxc package will need to explicitly switch packages if they want the full one. That's not the same behaviour as described in my quote comment.

[Liskni_si]

Right, I should have been more careful with the word "exactly". I don't think the proposed solution can be implemented, though.

If the "keepassxc" package is to be replaced by the two alternatives ("keepassxc-full" and "keepassxc-minimal"), you'd still need a transitional dummy package named "keepassxc". That package would depend on "keepassxc-full | keepassxc-minimal", giving the user a choice to satisfy the dependency by installing either of those. So far so good. What if the user doesn't explicitly choose, though? The idea is that an upgrade would keep the "-full" variant but "apt install keepassxc" would pull in the "-minimal" variant. How do you encode this in Debian package metadata?

I think both "apt install" and "apt full-upgrade" will simply choose the first alternative, so you get either "-full" in both scenarios, or "-minimal" in both.