5 ms·

Developers: Let distros do their job

theamk 5y ago
from this post: > Don’t ship pre-built binaries [...] Once you ship your [source] tarballs, your job is done. It’s the users who will go to their distro and ask for a new package. from author's own Sourcehut's project page [0] # Add the following line to /etc/apt/sources.list deb https://mirror.sr.ht/debian sid main # Install signing key wget -q https://mirror.sr.ht/debian/key.asc -O - | sudo apt-key --keyring /etc/apt/trusted.gpg.d/debian.sr.ht.gpg add - sure doesn't look like "shipping the tarball" to me :) [0] https://man.sr.ht/packages.md https://man.sr.ht/packages.md
- ddevault 5y ago
  SourceHut maintains actual package repositories based on standard package managers, most of which are overseen by independent contributors. The Debian packages are maintained by Denis Laxalde, who is a volunteer with no relationship to SourceHut. This approach enjoys most of the same benefits as using upstream packages does - contrast this with, for example, shipping a bunch of Docker images. SourceHut is under heavy development and shipping multiple releases per day during busy weeks, and the workload of keeping up with it downstream is quite large. NixOS is working on it, but few other distros are brave enough to try. Once we ship 1.0 then it will make a lot more sense for distros to start maintaining their own packages for it, and their job will be made easier given that they can start by copy/pasting the interim package manifests maintained by these SourceHut-specific teams. On the whole I would argue that I'm walking the walk here.
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".

from this post: > Don’t ship pre-built binaries [...] Once you ship your [source] tarballs, your job is done. It’s the users who will go to their distro and ask for a new package. from author's own Sourcehut's project page [0] # Add the following line to /etc/apt/sources.list deb https://mirror.sr.ht/debian sid main # Install signing key wget -q https://mirror.sr.ht/debian/key.asc -O - | sudo apt-key --keyring /etc/apt/trusted.gpg.d/debian.sr.ht.gpg add - sure doesn't look like "shipping the tarball" to me :) [0] https://man.sr.ht/packages.md https://man.sr.ht/packages.md

ddevault 5y ago
SourceHut maintains actual package repositories based on standard package managers, most of which are overseen by independent contributors. The Debian packages are maintained by Denis Laxalde, who is a volunteer with no relationship to SourceHut. This approach enjoys most of the same benefits as using upstream packages does - contrast this with, for example, shipping a bunch of Docker images. SourceHut is under heavy development and shipping multiple releases per day during busy weeks, and the workload of keeping up with it downstream is quite large. NixOS is working on it, but few other distros are brave enough to try. Once we ship 1.0 then it will make a lot more sense for distros to start maintaining their own packages for it, and their job will be made easier given that they can start by copy/pasting the interim package manifests maintained by these SourceHut-specific teams. On the whole I would argue that I'm walking the walk here.

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".