This isn’t the project maintainer we’re talking about, it’s the Debian package maintainer. Their job is building a working .deb with working software, not randomly messing with it. Users have the right to demand their packages to be trustworthy.
> Their job is building a working .deb with working software
If that were was all there is to packaging - upstream developers could do the same job & have their CI/CD pipeline shoot out a .deb file.
However, it's not unheard of for package managers to maintain an evolving patchset that changes the default behavior and better integrates the upstream project to the rest of the distribution and its philosophy.
Upstream developers don’t have the time and bandwidth to set up packaging for all distros and versions.
Improving defaults may be fine according to some. Removing major features advertised by the software due to political reasons is not fine.
My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version). How is this “better integration with the philosophy”?
> My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version)
As a Debian stable devotee, this seems reasonable to me. If I wanted each package to bring along & manage its own dependencies, I'd use flatpaks.
> How is this “better integration with the philosophy”?
I'm guessing Bootstrap 3 wasn't yet in whatever release/channel your software was being packaged for?
Can't you imagine any possible benefits of not shipping bootstrap v2 and Bootstrap v3? Or do you just disagree with the Debian unstable -> testing -> stable philosophy? Dependency juggling is just one of the issues distro package maintainers have to wrangle with, that upstream maintainers typically don't care about - an upstream project can declare "this version requires the latest glibc", but distro packagers may have to patch around that because the latest version of glibc hasn't been through testing.
We ship a copy of bootstrap within our data files. They could just leave it as-is and have it working. Bootstrap is a CSS/JS library, there is no global /usr/lib to be concerned about.
It is trivial to make the Bootstrap 3 global package install into a different folder than Bootstrap 2. It isn’t so trivial for shared libraries without different sonames, for example.
I think one of the potentially bigger things that doesn't yet exist is an easy way for non-developers to build their own packages with whatever options they want. By easy I mean a GUI tool that works across the majority of projects out there, and on any distro.
> If that were was all there is to packaging - upstream developers could do the same job & have their CI/CD pipeline shoot out a .deb file.
That's what some users seem to want today. It's why both Flatpak and Snap exist with the goals of letting upstream developers just CI/CD spit out a "universal" package for Linux and getting a more "Mac-like" (or "Windows-like" if you prefer) install experience with less waiting for package maintainers to get around to publishing upstream changes.
Admittedly, Flatpak and Snap aren't universally beloved either, yet, but the balance of what the job for a distro's package maintainers should be is definitely in shift.
Doing it in response to a single user’s bug report from 2020 that does not provide any rationale other than “network access bad” constitutes randomly messing with packages.
The feature flag is put there by upstream. If they don't want to support non-network installs then why do they even have that lever?
That said it probably makes more sense for Debian to package a `keepassxc-nonet` alongside the default `keepassxc` so end users can choose the variant.
If a user wants to build a hardened copy, they are free to do that. Distros should provide a version with standard features that are expected by end users.
As a Debian user I like how Debian just includes the basics in the main package and provides optional extras if you want them. I'm not sure how other distros handle it the other way around -- if the main package includes everything the risk is naive users install packages that include functions they don't need that end up exposing security issues. The Debian approach provides a reduced attack surface out of the box and if I happen to need something more its easy to just apt search ${package_name} and see what other extensions are available and install these. I do this regularly for PHP modules for instance if some PHP code complains a certain module is not available. It may not be your cup of tea but this is the Debian approach, and it makes sense from the perspective of a defensive user like me to keep things simple.
I agree, it's also supremely obnoxious that upgrading a piece of software means losing a lot of functionality - unless the user knows s/he needs to replace the package with the -full version..
Wahey, isn't that what MS does with e.g. Outlook. Congrats Debian, you're reaching Microsoft's level!
I agree that is unfortunate however I would argue the package should have been built that way in the first place. It's not the best thing to do now but better late than never. I wonder if the Debian maintainer would consider some sort of transactional package which brings in the new package if you had the original one installed. However, as someone who has used Keepass and did not realise it had all these extra functionalities, I think the assessment that most users will see no difference is ultimately closer to the truth than many people realise. I migrated away from Keepass specifically because I thought it had no network functions which makes all this drama especially ironic for a software that was marketed (at the time) as a password manager to keep on your own device and not someone else's machine.
This kind of thing is one of the reasons why we have different distros. For Debian, it's actually common to provide a "minimal" package plus one or more versions built with different feature flags.
Randomly messing with the code they package is the primary job of a debian packager. Which is how we get such great contributions from debian maintainers like the weak keys fiasco.
It can also work the other way around. When I install Apache on other distros I end up having to disable so many modules -- whereas the default Apache config in Debian is pretty watertight I never really have to mess around with modules. Likewise installing PHP only installs the core PHP module, you have to specifically install the extras. Other distros install everything including the kitchen sink. Needless to say, I'll take the Debian approach, warts and all.
What do you propose instead? Why should users always accept and agree with the Debian maintainers' choices, even if they're dumb and produce insecure software? Why should being a volunteer give you a get out of jail free card?
I propose request, rather than demand. If you don't agree with the maintainers choice and it is a legitimate issue, you could raise the issue with the Debian community and try to get some more support. Alternatively, suggest a fix that meets both requirements (such as a -full package).
There is no get out jail card here... just people volunteering their time, and a subset of users that feel they have some sort of entitlement. If I volunteer to pick up trash at my local park, would you demand that I pick up your garbage? No.. that would make you a jerk.
I'm an inactive Debian Maintainer and retired Ubuntu core dev, so perhaps my views are biased.. but I really think people should show these volunteers more respect.
