8 ms·

There are things like this. The things I know of and can think of off the top of my head are: 1. appimage https://appimage.org/ https://appimage.org/ 2. nix-

by TheDong 9mo ago

There are things like this. The things I know of and can think of off the top of my head are: 1. appimage https://appimage.org/ https://appimage.org/ 2. nix-bundle https://github.com/nix-community/nix-bundle https://github.com/nix-community/nix-bundle 3. guix via guix pack 4. A small collection of random small projects hardly anyone uses for docker to do this (i.e. https://github.com/NilsIrl/dockerc https://github.com/NilsIrl/dockerc ) 5. A docker image (a package that runs everywhere, assuming a docker runtime is available) 6. https://flatpak.org/ https://flatpak.org/ 7. https://en.wikipedia.org/wiki/Snap_(software) https://en.wikipedia.org/wiki/Snap_(software) AppImage is the closest to what you want I think.

amelius 9mo ago
AppImage looks like what I need, thanks. I wonder though, if I package say a .so file from nVidia, is that allowed by the license?
- c0balt 9mo ago
  Depends on the license and the specific piece of software. Redistribution of commercial software is may be restricted or require explicit approval. You generally still also have to abide by license obligations for OSS too, e. G., GPL. To be specific for the exampls, Nvidia has historically been quite restrictive (only on approval) here. Firmware has only recently been opened up a bit and drivers continue to be an issue iirc.
- mdavid626 9mo ago
  Don't forget - AppImage won't work if you package something with glibc, but run on musl/uclibc.
- direwolf20 9mo ago
  No, that's a copyright violation, and it won't run on AMD or Intel GPUs, or kernels with a different Nvidia driver version.
  - amelius 9mo ago
    But this ruins the entire idea of packaging software in a self-contained way, at least for a large class of programs. It makes me wonder, does the OS still take its job of hardware abstraction seriously these days?
    - holowoodman 9mo ago
      The OS does. Nvidia doesn't.
      - direwolf20 9mo ago
        Does Nvidia not support OpenGL?
        holowoodman 9mo ago
        Not really. Nvidia-OpenGL is incompatible to all existing OS OpenGL interfaces, so you need to ship a separate libGL.so if you want to run on Nvidia. In some cases you even need separate binaries, because if you dynamically link against Nvidia's libGL.so, it won't run with any other libGL.so. Sometimes also vice versa.
        direwolf20 9mo ago
        Does AMD use a statically linked OpenGL?
        holowoodman 9mo ago
        AMD uses the dynamically linked system libGL.so, usually Mesa.
        direwolf20 9mo ago
        So you still need dynamic linking to load the right driver for your graphics card.
- ValdikSS 9mo ago
  AppImage is not what you need. It's just an executable wrapper for the archive. To make the software cross-distro, you need to compile it manually on an old distro with old glibc, make sure all the dependencies are there, and so on. https://docs.appimage.org/reference/best-practices.html#binaries-compiled-on-old-enough-base-system https://docs.appimage.org/reference/best-practices.html#bina... There are several automation tools to make AppImages, but they won't magically allow you to compile on the latest Fedora and expect your executable to work on Debian Stable. It's still require quite a lot of manual labor.
  - ndiddy 9mo ago
    Yeah a lot of Appimage developers make assumptions about what their systems have as well (i.e. "if I depend on something that is installed by default on Ubuntu desktop then it's fine to leave out"). For example, a while ago I installed an Appimage GUI program on a headless server that I wanted to use via X11 forwarding. I ended up having to manually install a bunch of random packages (GTK stuff, fonts, etc) to get it to run. I see Appimage as basically the same as distributing Linux binaries via .tar.gz archives, except everything's in a single file.
- ValdikSS 9mo ago
  >I wonder though, if I package say a .so file from nVidia, is that allowed by the license? It won't work: drivers usually require exact (or more-or-less the same) kernel module version. That's why you need to explicitly exclude graphics libraries from being packaged into AppImage. This make it non-runnable on musl if you're trying to run it on glibc. https://github.com/Zaraka/pkg2appimage/blob/master/excludelist https://github.com/Zaraka/pkg2appimage/blob/master/excludeli...
- saidinesh5 9mo ago
  Typically appimage packaging excludes the .so files that are expected to be provided by the base distro. Any .so from nvidia is supposed to be one of those things. Because it also depends on the drivers etc.. provided by nvidia. Also on a side note, a lot of .so files also depends on other files in /usr/share , /etc etc... I recommend using an AppImage only for the happy path application frameworks they support (eg. Qt, Electron etc...). Otherwise you'd have to manually verify all the libraries you're bundling will work on your user's distros.
gilli 9mo ago
I wish AppImage was slightly more user friendly and did not require the user to specifically make it executable.
- VadimPR 9mo ago
  We fix this issue by distributing ours in a tar file with the executable bit set. Linux novices can just double click on the tar to exact it and double click again on the actual appimage. Been doing it this way for years now, so it's well battle tested.
  - account42 9mo ago
    That kind of defeats the point of an AppImage though - you could just as well have a tar archive with a c classic collection of binaries + optional launcher script.
    - VadimPR 9mo ago
      A single file is much better to manage on the eyes than a whole bunch of them, plus AppImages can be installed into the desktop using integration.
a022311 9mo ago
It should be noted that AppImages tend to be noticeably slower at runtime than other packaging methods and also very big for typical systems which include most libraries. They're good as a "compile once, run everywhere" approach but you're really accommodating edge cases here. A "works in most cases" build should also be available for that that it would benefit. And if you can, why not provide specialized packages for the edge cases? Of course, don't take my advice as-is, you should always thoroughly benchmark your software on real systems and choose the tradeoffs you're willing to make.
- saghm 9mo ago
  IMO one of the best features of AppImage is that it makes it easy to extract without needing external tools. It's usually pretty easy for me to look at an AppImage and write a PKGBUILD to make a native Arch package; the format already encodes what things need to be installed where, so it's only a question of whether the libraries it contains are the same versions of what I can pull in as dependencies (either from the main repos or the AUR). If they are, my job is basically already done, and if they aren't, I can either choose to include them in the package itself assuming I don't have anything conflicting (which is fine for local use even if it's not something that's usually tolerated when publishing a package) or stick with using the AppImage.
  - a022311 9mo ago
    I agree. I've seen quite a few AUR packages built that way and I'm using a few myself too. The end user shouldn't be expected to do this though! :D
    - saghm 9mo ago
      I agree with you as well! I don't think AppImage is perfect by any means. I do prefer it overall to the other commonly mentioned "universal" package tools like snap and flatpak, but I think my ideal system would essentially be a middleware protocol between build tool "frontends" and package format "backends" and then an ecosystem of tooling around that. LLVM and LSP haven't magically solved every issue with compilers and editor support for languages by any means, but they have significantly moved the needle on the average experience for quite a large number of end users even if they never directly touch any of the underlying protocols.

by TheDong 9mo ago

amelius 9mo ago

AppImage looks like what I need, thanks. I wonder though, if I package say a .so file from nVidia, is that allowed by the license?

c0balt 9mo ago
Depends on the license and the specific piece of software. Redistribution of commercial software is may be restricted or require explicit approval. You generally still also have to abide by license obligations for OSS too, e. G., GPL. To be specific for the exampls, Nvidia has historically been quite restrictive (only on approval) here. Firmware has only recently been opened up a bit and drivers continue to be an issue iirc.
mdavid626 9mo ago
Don't forget - AppImage won't work if you package something with glibc, but run on musl/uclibc.
direwolf20 9mo ago
No, that's a copyright violation, and it won't run on AMD or Intel GPUs, or kernels with a different Nvidia driver version.
- amelius 9mo ago
  But this ruins the entire idea of packaging software in a self-contained way, at least for a large class of programs. It makes me wonder, does the OS still take its job of hardware abstraction seriously these days?
  - holowoodman 9mo ago
    The OS does. Nvidia doesn't.
    - direwolf20 9mo ago
      Does Nvidia not support OpenGL?
      - holowoodman 9mo ago
        Not really. Nvidia-OpenGL is incompatible to all existing OS OpenGL interfaces, so you need to ship a separate libGL.so if you want to run on Nvidia. In some cases you even need separate binaries, because if you dynamically link against Nvidia's libGL.so, it won't run with any other libGL.so. Sometimes also vice versa.
        direwolf20 9mo ago
        Does AMD use a statically linked OpenGL?
        holowoodman 9mo ago
        AMD uses the dynamically linked system libGL.so, usually Mesa.
        direwolf20 9mo ago
        So you still need dynamic linking to load the right driver for your graphics card.
ValdikSS 9mo ago
AppImage is not what you need. It's just an executable wrapper for the archive. To make the software cross-distro, you need to compile it manually on an old distro with old glibc, make sure all the dependencies are there, and so on. https://docs.appimage.org/reference/best-practices.html#binaries-compiled-on-old-enough-base-system https://docs.appimage.org/reference/best-practices.html#bina... There are several automation tools to make AppImages, but they won't magically allow you to compile on the latest Fedora and expect your executable to work on Debian Stable. It's still require quite a lot of manual labor.
- ndiddy 9mo ago
  Yeah a lot of Appimage developers make assumptions about what their systems have as well (i.e. "if I depend on something that is installed by default on Ubuntu desktop then it's fine to leave out"). For example, a while ago I installed an Appimage GUI program on a headless server that I wanted to use via X11 forwarding. I ended up having to manually install a bunch of random packages (GTK stuff, fonts, etc) to get it to run. I see Appimage as basically the same as distributing Linux binaries via .tar.gz archives, except everything's in a single file.
ValdikSS 9mo ago
>I wonder though, if I package say a .so file from nVidia, is that allowed by the license? It won't work: drivers usually require exact (or more-or-less the same) kernel module version. That's why you need to explicitly exclude graphics libraries from being packaged into AppImage. This make it non-runnable on musl if you're trying to run it on glibc. https://github.com/Zaraka/pkg2appimage/blob/master/excludelist https://github.com/Zaraka/pkg2appimage/blob/master/excludeli...
saidinesh5 9mo ago
Typically appimage packaging excludes the .so files that are expected to be provided by the base distro. Any .so from nvidia is supposed to be one of those things. Because it also depends on the drivers etc.. provided by nvidia. Also on a side note, a lot of .so files also depends on other files in /usr/share , /etc etc... I recommend using an AppImage only for the happy path application frameworks they support (eg. Qt, Electron etc...). Otherwise you'd have to manually verify all the libraries you're bundling will work on your user's distros.

gilli 9mo ago

I wish AppImage was slightly more user friendly and did not require the user to specifically make it executable.

VadimPR 9mo ago
We fix this issue by distributing ours in a tar file with the executable bit set. Linux novices can just double click on the tar to exact it and double click again on the actual appimage. Been doing it this way for years now, so it's well battle tested.
- account42 9mo ago
  That kind of defeats the point of an AppImage though - you could just as well have a tar archive with a c classic collection of binaries + optional launcher script.
  - VadimPR 9mo ago
    A single file is much better to manage on the eyes than a whole bunch of them, plus AppImages can be installed into the desktop using integration.

a022311 9mo ago

It should be noted that AppImages tend to be noticeably slower at runtime than other packaging methods and also very big for typical systems which include most libraries. They're good as a "compile once, run everywhere" approach but you're really accommodating edge cases here. A "works in most cases" build should also be available for that that it would benefit. And if you can, why not provide specialized packages for the edge cases? Of course, don't take my advice as-is, you should always thoroughly benchmark your software on real systems and choose the tradeoffs you're willing to make.

saghm 9mo ago
IMO one of the best features of AppImage is that it makes it easy to extract without needing external tools. It's usually pretty easy for me to look at an AppImage and write a PKGBUILD to make a native Arch package; the format already encodes what things need to be installed where, so it's only a question of whether the libraries it contains are the same versions of what I can pull in as dependencies (either from the main repos or the AUR). If they are, my job is basically already done, and if they aren't, I can either choose to include them in the package itself assuming I don't have anything conflicting (which is fine for local use even if it's not something that's usually tolerated when publishing a package) or stick with using the AppImage.
- a022311 9mo ago
  I agree. I've seen quite a few AUR packages built that way and I'm using a few myself too. The end user shouldn't be expected to do this though! :D
  - saghm 9mo ago
    I agree with you as well! I don't think AppImage is perfect by any means. I do prefer it overall to the other commonly mentioned "universal" package tools like snap and flatpak, but I think my ideal system would essentially be a middleware protocol between build tool "frontends" and package format "backends" and then an ecosystem of tooling around that. LLVM and LSP haven't magically solved every issue with compilers and editor support for languages by any means, but they have significantly moved the needle on the average experience for quite a large number of end users even if they never directly touch any of the underlying protocols.