4 ms·

That's easy. It should be officially in Debian. ;-) Stuff like AppImage, static binaries, Docker & Co are for me at least a kind of "last resort". Even I'm usi

That's easy. It should be officially in Debian. ;-) Stuff like AppImage, static binaries, Docker & Co are for me at least a kind of "last resort". Even I'm using Docker a lot[1] to try things out I first look for an AppImage in those cases. But when I decide that some app should become part of my system I will look for a proper package. One source to rule them all… [1] Docker is a big problem on it's own. But as I can't avoid to have it installed because of work I decided I could use it at least to "keep experiments under control". Before I was forced to have Docker I've used systemd-nspawn for that use-case.

petre 6y ago
Debian has a lot of rules, some of which prevent statically linked binaries, like Go programs, from being packaged and shipped with it. A notable example is lxd. Appimages are great but there's no sandboxing or updates. But hey, we used to downlad debs and install them by hand on Debian 1.3, before apt was a thing. Maybe appimages could be signed and distributed in a similar fashion.
- viraptor 6y ago
  > prevent statically linked binaries, like Go programs What do you mean? There's debian go packaging team: https://go-team.pages.debian.net/ https://go-team.pages.debian.net/ as well as go packages in stable (for example https://packages.debian.org/buster/influxdb https://packages.debian.org/buster/influxdb)
- ReallyOldLurker 6y ago
  "Appimages are great but there's no sandboxing or updates" Actually there is sandboxing and updates, if you want to take an extra steps. I prefer AppImages over Flatpack and Snaps for essentially the same reasons commented above. I typically launch them with Firejail for the sandboxing. i.e. "firejail --appimage /path/to/appimage" instead of just the appimage alone. Seems to work just fine. Firejail has additional options that can be done. Some AppImage creators do provide an update method that can be installed using zsync2, but I've not tried it since the whole point is disposability.
- cyphar 6y ago
  Go programs are not (generally speaking) statically linked, unless you're explicitly doing CGO_ENABLED=0, -tags 'netgo' and the whole variety of other tricks needed to coax static binaries out of the compiler. Try running "ldd" or "file" on your Go binaries -- most of the time they'll be dynamic objects and linked to glibc, especially if you're just doing a stock "go build". In addition, Debian definitely does package Go programs -- they've packaged some of mine and they have possibly the most ambitious way of solving the great vendor/ issue (which most other distributions have ignored). The likely issue with LXD is that they require specific versions of various system libraries that they package in their source code bundles (including a fork of sqlite3!). I packaged LXD for openSUSE[1]. It wasn't really fun, but it is fairly doable if you have a flexible enough view on "good packaging practices" (and I imagine Debian packagers didn't feel like going through all the necessary workarounds -- which includes patching the ELF binary in the openSUSE case). And note that LXD isn't even a static binary -- I tried to compile it statically to get around a whole range of issues and it was a nightmare. [1]: https://build.opensuse.org/package/show/Virtualization:containers/lxd https://build.opensuse.org/package/show/Virtualization:conta...
- Izkata 6y ago
  > Appimages are great but there's no sandboxing or updates. I know nothing about AppImages, but up above someone said they do have updates: https://news.ycombinator.com/item?id=23773878 https://news.ycombinator.com/item?id=23773878
- pjmlp 6y ago
  Go also supports dynamic linking actually.
  - pabs3 6y ago
    Unfortunately even micro releases of the Go compiler break ABI, so Go dynamic linking isn't feasible for distros to use: https://wiki.debian.org/StaticLinking#Go https://wiki.debian.org/StaticLinking#Go
    - cyphar 6y ago
      There are two types of "static linking" being discussed: * Linking with system libraries (what GP mentioned). * Linking with Go packages (what you're talking about). Yes, Go doesn't really support -buildmode=shared anymore (and it was pretty broken from the outset). But this is a separate question to whether a Go binary is actually a static object. In most cases (and by default), Go binaries are dynamically linked to system libraries (with Go packages being statically linked into the program).
      - pabs3 6y ago
        pjmlp's comment seemed to be about Go packages to me, not system libraries.
        cyphar 6y ago
        The original comment[1] spoke about "statically linked binaries" which has a pretty specific meaning ("file" says its a static binary). There are similar issues for Debian packaging if you had a hypothetical language which required you to vendor your dependencies because maintenance for security issues would be annoying (Debian worked around this problem in Go through "de-vendoring" and Go modules -- in theory -- mostly solve this issue today). But static binaries are generally not distributed in distributions because they make make core library updates worse in terms of download size as well as inflating memory usage due to lack of page-cache sharing. [1]: https://news.ycombinator.com/item?id=23773480 https://news.ycombinator.com/item?id=23773480
pantalaimon 6y ago
Where can I find an up to date guide on how to package software for Debian and what to do to get it included in the repository? I’ve often came across orphaned packages where Debian was stuck with an old version, but didn’t know what to do about it other than installing from source. Or using a PPA if I was lucky.
- paxswill 6y ago
  For the first part, I found Debian’s Maintainers’ Guide [0] pretty helpful when I was updating xscreensaver last year (hasn’t been uploaded yet though...). It also has a section at the beginning concerning how to adopt orphaned packages. For upstream updates, some projects will have a way to create deb packages themselves, which can make installation/updates easier later on (concrete example, with OpenZFS can create RPMs and debs from the upstream tree). 0: https://www.debian.org/doc/manuals/debmake-doc/index.en.html https://www.debian.org/doc/manuals/debmake-doc/index.en.html

petre 6y ago

Debian has a lot of rules, some of which prevent statically linked binaries, like Go programs, from being packaged and shipped with it. A notable example is lxd. Appimages are great but there's no sandboxing or updates. But hey, we used to downlad debs and install them by hand on Debian 1.3, before apt was a thing. Maybe appimages could be signed and distributed in a similar fashion.

viraptor 6y ago
> prevent statically linked binaries, like Go programs What do you mean? There's debian go packaging team: https://go-team.pages.debian.net/ https://go-team.pages.debian.net/ as well as go packages in stable (for example https://packages.debian.org/buster/influxdb https://packages.debian.org/buster/influxdb)
ReallyOldLurker 6y ago
"Appimages are great but there's no sandboxing or updates" Actually there is sandboxing and updates, if you want to take an extra steps. I prefer AppImages over Flatpack and Snaps for essentially the same reasons commented above. I typically launch them with Firejail for the sandboxing. i.e. "firejail --appimage /path/to/appimage" instead of just the appimage alone. Seems to work just fine. Firejail has additional options that can be done. Some AppImage creators do provide an update method that can be installed using zsync2, but I've not tried it since the whole point is disposability.
cyphar 6y ago
Go programs are not (generally speaking) statically linked, unless you're explicitly doing CGO_ENABLED=0, -tags 'netgo' and the whole variety of other tricks needed to coax static binaries out of the compiler. Try running "ldd" or "file" on your Go binaries -- most of the time they'll be dynamic objects and linked to glibc, especially if you're just doing a stock "go build". In addition, Debian definitely does package Go programs -- they've packaged some of mine and they have possibly the most ambitious way of solving the great vendor/ issue (which most other distributions have ignored). The likely issue with LXD is that they require specific versions of various system libraries that they package in their source code bundles (including a fork of sqlite3!). I packaged LXD for openSUSE[1]. It wasn't really fun, but it is fairly doable if you have a flexible enough view on "good packaging practices" (and I imagine Debian packagers didn't feel like going through all the necessary workarounds -- which includes patching the ELF binary in the openSUSE case). And note that LXD isn't even a static binary -- I tried to compile it statically to get around a whole range of issues and it was a nightmare. [1]: https://build.opensuse.org/package/show/Virtualization:containers/lxd https://build.opensuse.org/package/show/Virtualization:conta...
Izkata 6y ago
> Appimages are great but there's no sandboxing or updates. I know nothing about AppImages, but up above someone said they do have updates: https://news.ycombinator.com/item?id=23773878 https://news.ycombinator.com/item?id=23773878
pjmlp 6y ago
Go also supports dynamic linking actually.
- pabs3 6y ago
  Unfortunately even micro releases of the Go compiler break ABI, so Go dynamic linking isn't feasible for distros to use: https://wiki.debian.org/StaticLinking#Go https://wiki.debian.org/StaticLinking#Go
  - cyphar 6y ago
    There are two types of "static linking" being discussed: * Linking with system libraries (what GP mentioned). * Linking with Go packages (what you're talking about). Yes, Go doesn't really support -buildmode=shared anymore (and it was pretty broken from the outset). But this is a separate question to whether a Go binary is actually a static object. In most cases (and by default), Go binaries are dynamically linked to system libraries (with Go packages being statically linked into the program).
    - pabs3 6y ago
      pjmlp's comment seemed to be about Go packages to me, not system libraries.
      - cyphar 6y ago
        The original comment[1] spoke about "statically linked binaries" which has a pretty specific meaning ("file" says its a static binary). There are similar issues for Debian packaging if you had a hypothetical language which required you to vendor your dependencies because maintenance for security issues would be annoying (Debian worked around this problem in Go through "de-vendoring" and Go modules -- in theory -- mostly solve this issue today). But static binaries are generally not distributed in distributions because they make make core library updates worse in terms of download size as well as inflating memory usage due to lack of page-cache sharing. [1]: https://news.ycombinator.com/item?id=23773480 https://news.ycombinator.com/item?id=23773480

pantalaimon 6y ago

Where can I find an up to date guide on how to package software for Debian and what to do to get it included in the repository? I’ve often came across orphaned packages where Debian was stuck with an old version, but didn’t know what to do about it other than installing from source. Or using a PPA if I was lucky.

paxswill 6y ago
For the first part, I found Debian’s Maintainers’ Guide [0] pretty helpful when I was updating xscreensaver last year (hasn’t been uploaded yet though...). It also has a section at the beginning concerning how to adopt orphaned packages. For upstream updates, some projects will have a way to create deb packages themselves, which can make installation/updates easier later on (concrete example, with OpenZFS can create RPMs and debs from the upstream tree). 0: https://www.debian.org/doc/manuals/debmake-doc/index.en.html https://www.debian.org/doc/manuals/debmake-doc/index.en.html