Thank you to all the Debian volunteers that make Debian and all its derivatives possible. It's remarkable how many people and businesses have been enabled by your work. Thank you!
On a personal note, Trixie is very exciting for me because my side project, ntfy [1], was packaged [2] and is now included in Trixie. I only learned about the fact that it was included very late in cycle when the package maintainer asked for license clarifications. As a result the Debian-ized version of ntfy doesn't contain a web app (which is a reaaal bummer), and has a few things "patched out" (which is fine). I approached the maintainer and just recently added build tags [3] to make it easier to remove Stripe, Firebase and WebPush, so that the next Debian-ized version will not have to contain (so many) awkward patches.
As an "upstream maintainer", I must say it isn't obvious at all why the web app wasn't included. It was clearly removed on purpose [4], but I don't really know what to do to get it into the next Debian release. Doing an "apt install ntfy" is going to be quite disappointing for most if the web app doesn't work. Any help or guidance is very welcome!
> The webapp is a nodejs app that requires packages that are not currently in debian.
Since vendoring dependencies inside packages is frowned upon in Debian, the maintainer would have needed to add those packages themselves and maintain them. My guess is that they didn't want to take on that effort.
Nodejs itself is, but when you install a node project manually, you type npm install and wait while it downloads the 500 different packages it depends on.
Debian follows the same philosophy as for other more traditional languages and expects that all these dependencies are packaged as individual Debian packages.
Just jumping in to say that this is making me genuinely reconsider adopting a licence/policy that forbids repackaging: the fact that someone can repackage my project, but worse, and still use my project's name? Absolutely not. I do not want the burden that inevitably comes when people complain to me that this or that is missing from a repackage.
I mean, that's just how OSS works. Anyone can fork your thing, do whatever, and call it a day. Going MIT or whatever won't save you either - this repackaging business is basically the entire business model of AWS.
Forking is fine, do whatever, but as soon as you make actual changes to the code then adopt your own name. This is what trademarks are for, it's just that official trademark registration is somewhat inaccessible (eg: cost) for open source projects. Could you imagine trademarking every little project you make just in-case it gets repackaged by someone who tears huge chunks of it out?
As it turns out, trademarks for small open-source projects are effectively worthless (https://news.ycombinator.com/item?id=44883634), so there's effectively no real solution to people appropriating your project's name while repackaging their inferior fork of it.
Debian sources need to be sufficient to build. So for npm projects, you usually have a debian-specific package.json where each npm dependency (transitively, including devDependencies needed for build) needs to either be replaced with its equivalent debian package (which may also need to be ported), vendored (usually less ideal, especially for third-party code), or removed. Oh, and enjoy aligning versions for all of that. That's doable but non-trivial work with such a sizable lockfile. If I would guess the maintainer couldn't justify the extra effort and taking on combing through all those packages.
I also think in either case the Debian way would probably be to split it out as a complementary ntfy-web package.
> As a result the Debian-ized version of ntfy doesn't contain a web app (which is a reaaal bummer), and has a few things "patched out" (which is fine).
My advise to you is to deny all support from people using the Debian version of your software and automatically close all bug tickets from Debian saying you don’t support externally patched software.
You would be far from the first to do so and it’s a completely rational and sane decision. You don’t have to engage with the insanity that Debian own policies force on its maintainers and users.
I agree that maintainers should not be expected to support patched versions of their software, but as a user I like the Debian policies you call insane. I would actually pick Debian exactly because they are cautious with the dependencies.
Debian is not cautious with the dependencies. Debian breaks a lot of what they ship, sometimes flagrantly like removing a whole feature, sometimes insiduously by introducing new bugs. I don't really care that Debian doesn't view it as breaking things. From my point of view, users trying to get my product get subpar experience in a way which is far from explicit.
I personally wouldn't use Debian but people are free to do whatever they want. I don't want to waste my time dealing with Debian maintainers and how they think software should work however. I advise all software developers to do the same and am vocal about it because it's easy to get guilt tripped in the idea that you should somehow support their users because they want to use your product or that introducing changes to support their esoteric targets somehow make sense because they have done the work despite the burden of futur support actually landing on you.
I want to make clear to people who decide they have no interest in it that they are not alone and it's perfectly fine.
And to be clear, I am singling Debian here because they are by far the worst offender when it comes to patching but the comment applies equaly to any distributions that apply invasive patches.
Debian IS more cautious with dependencies, in that you won't get hidden dependencies that aren't in the repos.
I don't want to install an app that downloads and executes 500 node packages that I don't know what they do. Those packages should already be vetted and in Debian. If not, then I'm not interested.
Side stepping the distro repos for dependencies for software in the repos leads to unexpected behavior.
> Debian IS more cautious with dependencies, in that you won't get hidden dependencies that aren't in the repos.
For a definition of cautious I don't personally share.
Debian doesn't vet packages. Debian maintainers are less competent than the "upstream" they question approximately all the time, which is why they keep breaking stuff in more or less severe way (OpenSLL anyone?). And let's not even talk about the insane stuff like when maitainers decide to support a fork they like instead of the piece of software users actually want (Libav anyone?).
> If not, then I'm not interested.
And that's your choice. That doesn't mean developers should care, nor that it is actually a good idea.
Eventually, someone must take source code and build and package the software.
When it's Debian maintainers, one at least knows the rules they are operating by.
For random people on the internet, it's usually more difficult to evaluate, vet them, and trust what they are doing.
Of course, I don't know you personally nor any software package that you are releasing so this is not an observation directed to you.
I can agree that debian maintainers are generally more incompetent, but they do actually vet dependencies for conforming to Debian ideology.
Upstream may be developing malware, they may be adding telemetry or ads. So if we just allow them to install 500 node packages that we don't know what they do... That's suspicious. That's asking for trouble.
Debian keeps a tight control on its supply chain. Its not perfect or bug free - but, it is within Debians goals.
So if you want a free distro with almost completely free sources, then Debian is really one of your only choices.
On a personal note, Trixie is very exciting for me because my side project, ntfy [1], was packaged [2] and is now included in Trixie. I only learned about the fact that it was included very late in cycle when the package maintainer asked for license clarifications. As a result the Debian-ized version of ntfy doesn't contain a web app (which is a reaaal bummer), and has a few things "patched out" (which is fine). I approached the maintainer and just recently added build tags [3] to make it easier to remove Stripe, Firebase and WebPush, so that the next Debian-ized version will not have to contain (so many) awkward patches.
As an "upstream maintainer", I must say it isn't obvious at all why the web app wasn't included. It was clearly removed on purpose [4], but I don't really know what to do to get it into the next Debian release. Doing an "apt install ntfy" is going to be quite disappointing for most if the web app doesn't work. Any help or guidance is very welcome!
[1] https://github.com/binwiederhier/ntfy
[2] https://tracker.debian.org/pkg/ntfy
[3] https://github.com/binwiederhier/ntfy/pull/1420
[4] https://salsa.debian.org/ahmadkhalifa/ntfy/-/blob/debian/lat...