I think that you just need to provide .tar of your app. Everything else should be problem for people who handle packages of different distros. You don't wanna be involved in that part of distribution. If people want your app, someone will make a package. There are too many package manages for you to run and add your stuff to all of them. Just have .tar on static http server and that's it!
Example: http://ftp.klid.dk/ftp/gnu/gcc/
> It's a problem for my potential users. I don't get this "it's not your job to distribute your own software".
Your users on these platforms that you don't seem to understand, aren't expecting _you_ to package your own software, they want the maintainers of their distribution to package it, as they know the distribution, which you probably don't.
Large part of the point of using distributions like Debian and Ubuntu is exactly this, that there are people deeply familiar and knowledgable about the distribution itself, who package the software and apply any needed patches, or wrangle it into what's the standard for the distribution.
When something isn't packaged for these users but they feel like it's popular/useful enough to be, they'll open a request with their distribution for someone to maintain that, in the distribution itself, so everything is aligned. Even though they're not supposed to, some users will bother you and ask you to package it for them, which isn't correct and shouldn't be like that. They either package it themselves, or ask their distribution to do it for them, as the packaging shouldn't have anything to do with the developer of the software.
That’s naive. Most users want to use a given piece of software. If they can’t, they usually consider that a defect of the software in question. The users that know and care enough to complain to their distro maintainers are not representative enough and are rare enough to make this a laggy at best, nonfunctional at worst (see TFA’s mention of having to package a bunch of dependency libs as their own packages) approach.
Distro maintainer curation is a godsend for security and reliability. Distro maintainers and people who work with them to get things packaged are heroes. But let’s not pretend that maintainer curation is something the average user trying to run a new piece of software cares about.
> Most users want to use a given piece of software. If they can’t, they usually consider that a defect of the software in question.
You somehow seem to be under the impression that all users are the same, which evidently they're not, then we wouldn't have many distributions.
Of course, most macOS and Windows users think exactly like how you outline. But the typical Debian, Ubuntu or Arch user don't think like that, as they typically understand what kind of environment and ecosystem they're in, where they don't expect every software developer to understand every distribution.
> But let’s not pretend that maintainer curation is something the average user trying to run a new piece of software cares about.
What in my comments gave you the impression that I'm trying to argue for this at all? Of course they don't care, otherwise they'd be maintainers themselves.
> What in my comments gave you the impression that I'm trying to argue for this at all? Of course they don't care, otherwise they'd be maintainers themselves.
You said:
> When something isn't packaged for these users but they feel like it's popular/useful enough to be, they'll open a request with their distribution for someone to maintain that
I don’t think that happens nearly often or quickly enough for most users to be satisfied. Hence why so much software is released through tertiary PPAs or .deb download links and so on.
Parent post already told you a way to distribute your software to Linux users; assuming your tarballs with prebuilt binaries "just work", as in, it's enough to untar it wherever (/opt?) and create a symlink in $PATH for your executable.
But from your comments, the message I get is that you want to apply to become a maintainer in each and every Linux distribution's package repositories, both mainstream and niche? And apparently also create packages for some alternative package managers too? (e.g. mise, npm, Terra)
Memory tracker to detect double free, and other common errors in C. Also for tracking all your allocation and stuff that yoir program does with memory.
Yup. But from my expirance cmake only becomes useful when you want to compile something on multiple os-es. I have not compiled brplot on windows or on mac. Makefile is written with linux as host os in mind.
It'd be cool to have cmake build option. So that you could create vs proj on windows, xcode proj on mac.
Requirments are a pain. On different distributions they are located in different packages. I should install top 20 most used distributions and try to build on that distributin. That would be quite a fun process.
That's why I stick with Ubuntu (well Linux Mint actually). I have yet to run into a project or problem which didn't had instructions specifically for Ubuntu.
You can also explore building with Nix to be platform/distribution agnostic.
Nope! I use Nix on macOS every day. I also use it on Ubuntu.
On Linux-based operating systems, you can even use `nix bundle` to create Docker images or fat binaries that end users can run without having Nix installed. (This relies on Linux user namespaces, which is why it's a Linux-only feature.)
