4 ms·
The problem is that there is always software in the long-tail distribution of popularity that isn't in the distributions official repositories due to lack of di
by sigotirandolas 5y ago
The problem is that there is always software in the long-tail distribution of popularity that isn't in the distributions official repositories due to lack of distribution's maintainers time.
I always, 100% of the time end up with software installed outside of the distribution's official repositories on my desktop systems. And right now sometimes installing it means compiling it myself, sometimes it means installing a .deb manually, sometimes it's adding a third-party repository, sometimes extracting a .tar.gz to /opt, and usually with a few lines of bash to get the binaries in PATH and .desktop files to work like any other distribution package. And often with no automatic updates nor signature checks.
I wish distributions could standardize more on their packaging formats, repository formats and filesystem hierachy, to the point where upstreams could ship their "canonical" version of the package (ideally source+binary) which could be used on mainstream distributions. This would not only help users who need software which is not on the distribution's repositories, but it would also make it easier for distributions to package software "up to their standards" for their official repositories since much of the menial work would be gone or already done upstream, once.
Right now it's the wild west. The universal solution for upstreams to ship source packages is putting the build instructions in a README and letting the user figure it out, and the universal solution for upstreams to ship binary packages is shipping a copy of the software with all its dependency tree since the only truly standard the distribution provides is "there's a Linux kernel".