Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Having a _completely_ different extension/package paradigm for every major and minor piece of software is not a user-friendly approach.

The central problem is that from an upstream author's perspective, distro package management is a nightmare.

Once upon a time, I tried maintaining Debian and RPM packages for my software. The process to become a Debian package maintainer was incredibly onerous and bureaucratic. Furthermore, dpkg is designed around the idea that you really should have exactly one version of each dependency across an entire system, for every piece of software that depends on it. And finally, the Debian stable version was usually years out of date.

RPM-based distributions had their own problems: Different, incompatible RPM features, dependency hell, etc. And of course, between dpkg and RPM, there were a half-dozen popular Linux distros, and two popular "distro" package managers on the Mac.

So I gave up. I distribute virtually all of my software using "language" package managers like bundler, npm and cargo. (And the rest as statically linked musl-libc binaries or Docker images.) These have top-notch support for dependency management, semantic versioning, and cross-platform builds. They're about a decade more advanced that dpkg or RPM for the things I care about. And if for some reason I need a GUI app, there's always Electron.

With cargo, TravisCI and AppVeyor, I can package a CLI tool for every popular system (including Windows) in a weekend, with automated cross-platform tests, and I'll rarely ever think about it again. And all my users can always get the latest versions, not three-year-old versions.

Anybody who wants to package my software for a distro is welcome to do so. I wash my hands of it all, and I'm extremely unlikely to provide any support.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: