Hello,
That is fine, there are no SLAs here, so they are free to not-support whatever they want. Supporting users is already time consuming. But per open source code licenses, I am also free to ignore their wishes to not package some software.
Funny enough I tried to do that and I was banned from the repository for breaking code of conduct xD Turns out going against the developers wishes, even if its legal, is against code of conduct.
Anyway to get back to your example, I imagine esc [0] is the kind of tool that would be used among many packages, so maybe it would be worth packaging if it was still maintained upstream. It outputs a binary and should be amenable to packaging. But since it's been dead for years... maybe not worth.
Only package dependencies when they are needed, if they are not needed no point packaging them. A lot of the libraries are only packaged when there is a application which depends on them.
Projects start because they scratch some personal itch, not usually because said dev has desire to become a packager or provide tech support to strangers. Even proper documentation is rare, much less proper packaging.
For some projects yes, its personal, but for some they are quite large software communities, which still do not document their code, or provide support for distributors. Hell, ever try packaging google software and you are in for a whole world of pain, google developers refuse to speak to me because I am inferior to them, and how dare I ask to package one of their open source applications. Currently working on the flutter package, I would speak to google developers directly through github but I feel it would go bad if some random arch user comes and asks for their support. I posted a question on their discord server... 3 weeks ago I think and got a response yesterday I believe, basically telling me to use their install script (which pulls binaries from googles servers, and part of the disclaimer is that google will take data and has an entire privacy policy on what they take for you simply installing flutter). So yeah, flutter is needed to build flutter native apps, which means somehow I got to throw together some method of working around these issues just so we can package flutter packages. I will continue to make my intentions heard within their discord community, and hopefully eventually one of the developers will give in and offer their support, some of the developers are open source contributors as far as I am aware, so maybe I am more likely to get one of them on my side :P All distros are falling to cross-distro packaging, nixos is the only other distro which I see standing firm for distro packaging, because of their strong empathsis on repro builds, but then again nixos developers and contributors get paid a lot of money to help out, mainly funded by big tech companies. The average salery I have heard for a nixos dev is $150,000 working at a big tech exclusively to contribute to nix. Of course this differs from arch greatly, arch never pays a penny for contributions, which has its pros and cons, the staff at arch are not driven by personal gain, as they gain nothing, but at the same time so many staff have full time jobs which take away the time they could put into the distro, but then again money always corrupts, it affects people in different ways but almost everyone has a price, I am sure a kernel dev would put a NSA vulnerability in if they were paid a hefty price, which is scary thinking about it, can we trust that touvalds hasn't let a dodgy patch slide hoping no contributors will notice the vulnerable code, its not like the NSA is going to stick a comment in the codebase saying "NSA VULNERABILITY, DO NOT TOUCH!!!". Anyways I went completely off topic again. So overrall golang package naming is just the application as golang statically links the modules in and therefore pops out an executable, therefore the need to package golang dependencies is mitigated? Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev