Hacker News Reader

Comment by pxc | Hacker News Reader

> having gone through this process I think I now understand why RPM packages are less commonly available compared to those for other distributions.

The most popular option of this kind, DEB, is actually even worse to work with imo, due to essentially similar kinds of problems. DEB is the most likely format to be supported by application vendors solely due to the popularity of Ubuntu.

If Fedora, rather than Ubuntu, was the distro of choice for newbies, dilettantes, and overburdened engineers who hope their choice of distro will afford them one fewer thing to focus on, then RPM would be the format Slack and Discord distribute for Linux. (And it would be about as much work for them as maintaining their DEB packages is for them now.)

View on HN

> The most popular option of this kind, DEB, is actually even worse to work with imo

Simply incorrect: https://xyrillian.de/thoughts/posts/argh-pm.html

Maybe interesting, but not actually relevant as far as I'm concerned.

When I'm packaging, I don't care about the archive format of the binary packages. I care about the contents inside the source package archives and the tooling and documentation for working with those files.

(I'm also not super interested in third-party tooling like the author of the linked blog post was working on. I don't want to use something like Holo or FPM or whatever and treat the binary archive as a glorified zip file, naive of the base system and its conventions. I want to conform to the policies and norms of the target distro as far as possible, vendoring as few deps as possible, running the same linters that distro developers are expected to use, etc.)

.spec file for tree: https://src.fedoraproject.org/rpms/tree-pkg/blob/rawhide/f/t...

I wonder if there's a way to write a DEB to RPM conversion script with automated testing etc, so Fedora gets to snarf up all existing DEBs :-)

there was something called alien that did this iirc

https://sourceforge.net/projects/alien-pkg-convert/

That approach is fundamentally broken because binaries from one distro aren't guaranteed to be compatible with binaries in another distro. Heck, even binaries from the same distro at different points in time can be incompatible with one another. There'd be incompatibilities across ABIs, compile time feature flags, system paths, and much more. There are plenty of assumptions about the system baked into binaries that aren't always trivial to fix.

Automated conversion can be helpful if you don't have access to the source code though. There are plenty of examples running proprietary software on unsupported distros using this approach. However, because of its shortcomings, it shouldn't be used when the source code is available.

Reply on news.ycombinator.com