Skip to content

Comment on Why developers should care about system packagesparent

Comments

Imagine I'm your average, workaday software developer.

If I've written some software to scratch a personal itch and I push it out to github because I reckon someone, somewhere might benefit at some arbitrary future point, or to show off to a future employer, or whatever, then I really do not care about making sure it compiles and works on a dozen distributions. Just getting it working to fix my problem, then publishing it, ticks all the boxes I'm interested in. After all, I've got fifteen other problems I need to solve this week, none of which involve spooling up VMs for distributions I never use.

If a packager then decides that their favourite distro would benefit from having my code packaged nicely, at what point does that become my responsibility? It Works For Me(tm), and beyond reviewing and applying patches other people might send me to improve it, I don't necessarily have any interest whatsoever in what happens outside my repository as long as it doesn't stop the code from solving my problem. It's possible that I might be both developer and packager for a distribution or two, but that's the exception, not the rule.

Personally, I think the right way is for a clear path from language-package to distro-package to be provided by my environment such that I don't have to think about it, and I think that the bulk of that responsibility should be shouldered by the distro - but it's insane to think that the language environment shouldn't help, because there is a mutual benefit there. I think we're nearly there with RVM and rubygems, but that's about as far from autotools as you can get.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.