Adding the repos of AM to `dbin`?

[xplshn]

Hi, this is an awesome project. Tho I haven't used it in a while because the programs here depend on glibc AFAIK. I was wondering if programs that were compiled using the '-s' option of go-appimage's appimagetool can be put in a repo that contains all of the binaries/AppImages in the same directory and also has a metadata file following this format:

{
    "name": "act",
    "description": "Run your GitHub Actions locally 🚀",
    "download_url": "https://bin.ajam.dev/x86_64_Linux/act",
    "size": "18.01 MB",
    "b3sum": "727836a6c4017d39db6a5af1664a8a5fbd6e2c74f310ae03856c18bcfbc28758",
    "sha256": "1b38281d93303507eba411b265fc313033da323f4afb80152dc01b3006eb9b04",
    "build_date": "2024-08-02T18:51:43",
    "repo_url": "https://github.com/nektos/act",
    "repo_author": "nektos",
    "repo_info": "Run your GitHub Actions locally 🚀",
    "repo_updated": "2024-08-26T03:14:54Z",
    "repo_released": "2024-08-01T02:26:58Z",
    "repo_version": "v0.2.65",
    "repo_stars": "53512",
    "repo_language": "Go",
    "repo_license": "MIT License",
    "repo_topics": "ci, devops, github-actions, golang",
    "web_url": "https://github.com/nektos/act"
  },

I can write a small program that creates/generates both the repo & its metadata in Go, but I'd have to be guided on how to do so, since I do not understand really how AM/AppMan are structured.

NOTE: I am only interested in completely self-contained binaries, since dbin is under the premise of: "📦 Poor man's package manager. +2510 statically linked binaries in the repos! The easy to use, easy to get, suckless software distribution system ".

[Samueru-sama]

As far as I know, besides my mpv appimage that has an issue, the only other projects that I know use the deploy everything mode are:

• flameshot, which their appimage for some reason doesn't follow my mouse cursor theme

• GIMP, but they only use their appimage in the CI since it also has some issues to be released for everyone.

I also tried to make this PR at helix but I don't think it will get thru: https://github.com/helix-editor/helix/pull/11243

It seems bundling glibc comes with its own set of issues like how statically linking glibc is also a problem.

[xplshn]

Glibc compiled binaries and libraries are 30% larger than Musl-based libraries and 50% larger than uClibc-ng ones.

It is perfectly possible to package programs from Alpine's repos as an appimage, the .apk format is really easy to understand, PKGINFO contains info about the package, and the format is just a tar with gzip compression, and the contents are FHS-compliant.

I thought that your self-contained binaries were using Musl, because using Glibc for anything that needs to be portable or static is almost impossible (and not efficient at all)

[xplshn]

As far as I know, besides my mpv appimage that has an issue, the only other projects that I know use the deploy everything mode are:

* flameshot, which their appimage for some reason doesn't follow my mouse cursor theme

* GIMP, but they only use their appimage in the CI since it also has some issues to be released for everyone.

I also tried to make this PR at helix but I don't think it will get thru: helix-editor/helix#11243

I was hoping to add some essential packages such as web browsers and office suites to dbin this way. :(

I can probably just set up some Github actions to use linuxdeploy with the qt&gtk plugins to generate the appdirs, then package them with PELF & go-appimage's appimagetool, the only issue with this approach is that I am not experienced with GH actions/workflows & linuxdeploy.

[Samueru-sama]

I can probably just set up some Github actions to use linuxdeploy with the qt&gtk plugins to generate the appdirs, then package them with PELF & go-appimage's appimagetool, the only issue with this approach is that I am not experienced with GH actions/workflows & linuxdeploy.

I can help you with linuxdeploy.

Although be aware that the deploy everything mode of go-appimage also has issues bundling musl, so I think what you are trying to do will only work if you compile the binary with a statically link musl before deploying.

I don't think this is easy though.

[xplshn]

Although be aware that the deploy everything mode of go-appimage also has issues bundling musl, so I think what you are trying to do will only work if you compile the binary with a statically link musl before deploying.

I don't know about that, I got a Thunar binary with just 2 commands, and it worked fine. And I did an ldd check and it said the binary was not a dynamic one. Of course I understand that more complex binaries will take much more than that. But such binaries could be an AppBundle instead of an AppImage. For example, to generate an mpv Appbundle that works across systems you do:

pelf --main-bin /usr/bin/mpv --output-to ./mpv.AppBundle --add-ld-and-libc /lib/ld-musl-x86_64.so.1 /lib/libc.musl-x86_64.so.1 --add-metadata /path/to/desktopFile --add-metadata /path/to/128x128.png --add-metadata /path/to/128x128.svg

I don't think this is easy though.

Nothing is ever easy :*

[Samueru-sama]

I got a Thunar binary with just 2 commands, and it worked fine

hey can I get a link to that thunar binary 👀

Of course I understand that more complex binaries will take much more than that. But such binaries could be an AppBundle instead of an AppImage

I really like what you are doing of making a truly universal format which appimage isn't one, but I have some concerns that hold me back from taking a deeper look into AppBundles, and one of those is the lack of compatibility with existing appimage tools.

The appimage spec mentions type 0 appimage, which is stuff that looks and behaves like an appimage but isn't one, have you considered making AppBundles be type 0?

Also how hard is it to make AppBundles compatible with aisap? https://github.com/mgord9518/aisap

[xplshn]

I got a Thunar binary with just 2 commands, and it worked fine

hey can I get a link to that thunar binary 👀

Of course I understand that more complex binaries will take much more than that. But such binaries could be an AppBundle instead of an AppImage

I really like what you are doing of making a truly universal format which appimage isn't one, but I have some concerns that hold me back from taking a deeper look into AppBundles, and one of those is the lack of compatibility with existing appimage tools.

The appimage spec mentions type 0 appimage, which is stuff that looks and behaves like an appimage but isn't one, have you considered making AppBundles be type 0?

Also how hard is it to make AppBundles compatible with aisap? https://github.com/mgord9518/aisap

What would a type 0 AppImage need to have in order to be an AppImage? Because I've been packaging some programs as AppBundles using go-appimage & linuxdeploy to remove their dependencies with patchelf.

I haven't look into how/what it is that aisap does, but it probably isn't hard if normal AppDirs can work with it

Thunar_File_Manager-6dee862-x86_64.AppImage.removeTheTxtPart.txt

[ivan-hc]

Aisap is a Bubblewrap frontend to sandbox AppImages

[xplshn]

Also how hard is it to make AppBundles compatible with aisap? https://github.com/mgord9518/aisap

So, the answer to the question is; Yes, as long as the AppRun provided to PELF can handle Aisap, appbundles will be able to use it. However, you cannot use --appimage* flags with PELF, if such compatibility is wanted, you can add that in your apprun.

[Samueru-sama]

I tried to run the mpv appbundle with aisap but I get :: failed to open bundle: unable to get AppImage type

What would a type 0 AppImage need to have in order to be an AppImage?

Well turns out AppBundles are already type0 appimage.

But it seems the applications expect a type 2 appimage instead with a certain magic byte. I don't know what aisap is looking for, the creator of aisap is also the creator of shimg which is an alternative runtime in shell (similar to PELF) which aisap itself comes as one, so it would be surprising if even shimg isn't supported by aisap.

[xplshn]

I tried to run the mpv appbundle with aisap but I get :: failed to open bundle: unable to get AppImage type

What would a type 0 AppImage need to have in order to be an AppImage?

Well turns out AppBundles are already type0 appimage.

But it seems the applications expect a type 2 appimage instead with a certain magic byte. I don't know what aisap is looking for, the creator of aisap is also the creator of shimg which is an alternative runtime in shell (similar to PELF) which aisap itself comes as one, so it would be surprising if even shimg isn't supported by aisap.

Yeah, aisap would have to use some kind of --appimage-$command to detect that its running an appimage, or --pbundle_help to check if its running an appbundle