4 ms·

Well there is something to do that. Exrm has some plugin to output a .deb. And it could be done for other package format. Once again, it is a tooling problem.

• derefr 10y ago
  The kind of .deb produced by Exrm (or by just packing up the release using FPM or the like) would never be accepted upstream by a distro maintainer. This is a political problem, in that distro vendors have strong philosophical stances on how to do packaging, and those stances make packaging Erlang programs to suit their tastes really hard (and frequently impossible for newer software, since they say things like "you must depend on the system erlang package rather than embedding ERTS; and the erlang package on LTS will be held at R16, so it doesn't support maps.") Of course, when people install your software "manually", you can distribute it however you like—a zip of an Erlang release, like a Java JAR, is already quite a convenient format for such installations all on its own. But when people want to install something that depends on your software (like, say, OpenStack depends on RabbitMQ), they don't want to spend nearly as much time thinking about your package. They don't know you exist, and they don't want to know you exist—they want the distro to handle that detail for them. So you're stuck fighting the distro. (And things like OpenStack are stuck doing non-distro-packaged releases to avoid the problem.) Which brings me back to my original point: "snaps" are promising not because they sandbox packages, but because they're a countervailing philosophical movement on how software should be packaged. A distro that supports snaps is a distro that has made room in its heart for packages that don't want to break things down into little FHS-arranged dep-graph-divided bits. It gives them an out, a place to put these packages rather than just denying them outright.