But that's not what they disagree with. They are saying you shouldn't have a package called "keepassxc" if it is missing a ton of features from upstream KeepassXC. You should name it something different instead.

So you shouldn't have "keepassxc" and "keepassxc-full". Instead you should have "keepassxc" and "keepassxc-minimal".

But it’s a valid build configuration option provided by upstream. Not sure I follow this line of reasoning.

Sure, I think that's a reasonable stance. If upstream agrees that such a configuration is a valid distribution of KeepassXC and can be branded KeepassXC, then that's up to them. I would probably disagree with upstream in that scenario just from a UX perspective, but I would understand both sides.

But in this case, upstream has responded and clearly indicated that they do not want the minimal distribution of KeepassXC to be branded as the main "keepassxc" package: https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

The default package should be named keepassxc-debian-limited or similar and the proper package should be keepassxc

OK? that has nothing to do with what I was correcting:

> IMHO is a downstream maintainer is going to change a package in a way that doesn't have the intent of the upstream project, it should be published under a different name and that maintainer deal with all bug reports caused by their modified version.

the downstream maintainer didn't "change a package in a way that doesn't have the intent of the upstream project", they altered the config flags in one package and made another with the previous flags. the maintainer is being a dick, but not in the way the OP suggested.

> the downstream maintainer didn't "change a package in a way that doesn't have the intent of the upstream project", they altered the config flags in one package and made another with the previous flags.

They altered the config flags in a way that doesn't have the intent of the upstream project. And I would classify build config changes as a subset of "changing a package".

Use JohnTHallerNix and it can be. Debian is again taking care of their users. Unlike upstream, Which isn't new. Did he do it in the best way? No. Did he do the right thing? Absolutely.

It's the tyranny inherent to dependency-hell monolithic package management. nix avoids this problem by permitting multiple versions and flexible configurations of the same package.

As stated in the GitHub thread [1]:

  You fundamentally misunderstand our program when you use the word plugin. These are
  built in features, not plugins. The features can be enabled as desired by the user and
  they come disabled by default. This change to not compile and ship these features in the
  base keepassxc package does nothing besides create angry (or confused) users.

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

That Canonical guy is not coming off brilliantly there. I appreciate that reasonable people can disagree on the best way to package this, but these kind of strong absolute statements – together with calling useful features "misguided" and "crap" – is not great, to put it mildly.

I'm pretty sure some compromise could theoretically be reached here. But not with that attitude. "It is our responsibility to our users to provide them the most secure option possible as the default"? You know what would be even more secure? To disable all networking in any program, and in fact, in Linux itself. Actually, it's even more secure to just not give people a computer at all. This is one of those stupid discussion-stoppers.

These kind of Highly Opinionated Maintainers™ has always been what put me off from Debian (and by extension, Ubuntu). I want to use KeePassXC, not "KeePassXC as some random guy thinks it should have been".

What's the alternative to Debian / Ubuntu now that CentOS is gone?

It really depends on your usecase; I'm personally fond of OpenSUSE and Alpine Linux. OpenSUSE is more "conventional" like Debian/RHEL, and Alpine is a touch idiosyncratic (mostly, musl as its libc means 3rd-party binaries often won't work) but is tiny ant fantastic when it does work for your usecase.

AlmaLinux and Rocky Linux are continuations of CentOS; I have no experience with either but that would be the logical place to start.

Arch Linux and Void Linux are both worth a look I'd say.

Rolling-release distros are unlikely to fit into the same usecase as a slow-moving stable-release distro.

I believe the zoomer response to this is "bruh"

Fedora

that seems completely irrelevant?

plugin, compile time ./configure flag, whatever - package maintainers extremely routinely create multiple versions of a package for various reasons, from security (this case) to dependencies (Debian contains a emacs-nox package that is emacs compiled without X libraries to avoid dragging them in on servers, for example) to license reasons.

again, all of the complaints are literally about the change, which the maintainer has decided to do in a disruptive fashion.

The problem is that this will break all existing users who use those features when they update. One of the comments in the GitHub thread has a better path, IMHO: ship two new packages, a -minimal and a -full, and the user to choose, rather than silently break functionality (NEWS is fine, but not really read by user as everyone admits).

Because I run and upgrade and suddenly all my shit stops working without warning, that's why. It's not how things should be done.