[ISSUE] Package request: am, or appman

[ISSUE] Package request: am, or appman

[ivelieu]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

New issue by ivelieu on void-packages repository

https://github.com/void-linux/void-packages/issues/54251

Description:
### Package name

am

### Package homepage

https://github.com/ivan-hc/AM

### Description

I know about #26702, but it would seem upstream is still reluctant to decouple from systemd.

`am` is 4 years old, stable, still maintained, and to be sure I have tried it out and the functionality works on Void. 
I know this ecosystem is not ideal. I don't like having to manage distro packages, flatpaks and appimages seperately. But flatpaks are incredibly space inefficient, and often this kind of packaged software in flatpaks/appimages won't meet the void package requirements because they may not be compiled. 

Just a trivial example: Joplin v3.2.12 appimage is 216 MB, compared to joplin on a fresh instance of flatpak which takes up 3.5 GB in `/var/lib/flatpak`. As far as I understand, a major drawback of appimages is the difficulty in updating which this proposal ameliorates.

`am` is the system version, `appman` is the user-only version. I am only requesting `am`, I include the other name here just so this can be searched/recognised more easily. It's just shell scripts, i.e. not compiled, but there is a strong argument it would be useful to many users.

Upstream is kind enough to provide [instructions for distro maintainers](https://github.com/ivan-hc/AM?tab=readme-ov-file#instructions-for-linux-distro-maintainers) to use it as well.

### Does the requested package meet the package requirements?

System

### Is the requested package released?

Yes

Re: Package request: am, or appman

[sgn]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

New comment by sgn on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2645988078

Comment:
- A bash script to manage AppImage.
- Likely you're the only user
- Download more scripts from that very own GitHub repository

NACK

Re: Package request: am, or appman

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2646018598

Comment:
[`appimaged`](https://github.com/probonopd/go-appimage/blob/master/src%2Fappimaged%2FREADME.md) might be fitting?

Re: Package request: am, or appman

[ivelieu]

[-- Attachment #1: Type: text/plain, Size: 322 bytes --]

New comment by ivelieu on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2646080849

Comment:
probonopd/go-appimage#209 
[Zap](https://github.com/srevinsaju/zap) has not been updated for 2 years and also only provides systemd, although appimaged has more systemd coupling.

Re: Package request: am, or appman

[Samueru-sama]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

New comment by Samueru-sama on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2655218738

Comment:
> A bash script to manage AppImage.

AM is more than just AppImages, it works with anything that's portable.

>Likely you're the only user

You gotta be kidding me, even @zen0bit who contributes here is an user and contributor of AM, it was recently added to the GUI installer of Rhino Linux and we were not even aware this happened, Ivan just happened to watch a distrotube video where this showed up (who also made a vid about am when it was starting). 

but sure thing, only one user.

Re: Package request: am, or appman

[Vinfall]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

New comment by Vinfall on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2716138304

Comment:
AM does not quite follow XDG base dir spec and running arbitrary code is indeed tricky.

How about [soar](https://github.com/pkgforge/soar)? It's compiled, uses only reproducible builds by default, caches database locally and also supports [external repo](https://docs.pkgforge.dev/repositories/external) (am, cargo-quickinstall, appimage.github.io and AppImageHub).

I only use it as AppImage manager and other portable binaries are managed via mise (and ubi backend), but it sounds a sane alternative that Void would accept (which would still take ages if no member is interested).

Re: Package request: am, or appman

[Vinfall]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

New comment by Vinfall on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2716138304

Comment:
AM does not quite follow XDG base dir spec and running arbitrary code is indeed tricky.

How about [soar](https://github.com/pkgforge/soar)? It's compiled, uses only reproducible builds by default, caches database locally and also supports [external repo](https://docs.pkgforge.dev/repositories/external) (am, cargo-quickinstall, appimage.github.io and AppImageHub). My main concern is it's too new and too ambitious for such a young project.

I only use it as AppImage manager and other portable binaries are managed via mise (and ubi backend), but it sounds a sane alternative that Void would accept (which would still take ages if no member is interested).

Re: Package request: am, or appman

[Samueru-sama]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

New comment by Samueru-sama on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2716146465

Comment:
> AM does not quite follow XDG base dir spec

Where does AM not follow the XDG Base dir spec? even when using `appman` it will go beyond the XDG spec and check for `XDG_BIN_HOME` before defaulting to `$HOME/.local/bin`. 

But anyways soar is good as well. I actually have [a project](https://github.com/pkgforge-dev/Anylinux-AppImages) with them lol

Re: Package request: am, or appman

[Vinfall]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

New comment by Vinfall on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2716276125

Comment:
> even when using `appman` it will go beyond the XDG spec and check for `XDG_BIN_HOME` before defaulting to `$HOME/.local/bin`.

You are right, sorry for the false claim🙇. After looking at my notes, it was appman touching my shell rc and $PATH without notice that makes me mad. And it would download another script instead of installing itself to ~/.local/bin. ~~In my notes I also complain about bash-completion but I already forgot how it's dirty.~~

Re: Package request: am, or appman

[Vinfall]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

New comment by Vinfall on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2716138304

Comment:
~~edit: AM does follow XDG base dir spec~~ but running arbitrary code is tricky.

How about [soar](https://github.com/pkgforge/soar)? It's compiled, uses only reproducible builds by default, caches database locally and also supports [external repo](https://docs.pkgforge.dev/repositories/external) (am, cargo-quickinstall, appimage.github.io and AppImageHub). My main concern is it's too new and their goal sounds too ambitious for such a young project.

I only use it as AppImage manager and other portable binaries are managed via mise (and ubi backend), but it sounds a sane alternative that Void would accept (which would still take ages if no member is interested).

Re: Package request: am, or appman

[Samueru-sama]

[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]

New comment by Samueru-sama on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2716297364

Comment:
> You are right, sorry for the false claim🙇. After looking at my notes, it was appman touching my shell rc and $PATH without notice that makes me mad. And it would download another script instead of installing itself to ~/.local/bin. ~In my notes I also complain about bash-completion but I already forgot how it's dirty.~

AM will only touch the shell rc when you install `appman` [here](https://github.com/ivan-hc/AM/blob/main/AM-INSTALLER#L46-L61)

This is because the [XDG Base dir spec says](https://specifications.freedesktop.org/basedir-spec/latest/#variables) that distro should make sure that `$HOME/.local/bin` is in `PATH`, the install script detects when that's not the case and will add a simple if statement to the end of the shell rc to add `export PATH="$PATH:$BINDIR"` so that everything works out of the box. 

I don't see a situation where this could cause an issue, we even added the if statement to make sure that export gets run only once.

The soar devs don't like that idea, but they already had to explain someone on their discord how to export soars bin dir to `PATH`, I have a feeling after a few users they will also automate this, specially because soar does not use `$HOME/.local/bin` so in this case user intervention is needed always to get that working.


--------------------------------------------------------------------------------

AM is the "most" XDG Base dir compliant software out there, 

* For example when you sandbox appimages with it, we try to bind mount the config dir of the existing application to the fakehome bindir, meaning that you don't have to transfer config files when you sandbox an application unlike others like flatpak or snap where you can to transfer the config files to `~/.var` or `~/snap`.

* We also don't make that mistake of having a hardcoded `~/.var` or `~/snap`, instead the sandboxed apps homes by default are placed in `$HOME/.local/am-sandboxes` and you can move the location by setting the `SANDBOXIDR` env variable.

* And as you already saw, we make sure `XDG_BIN_HOME` gets added to `PATH` if we detect it isn't. 

Re: Package request: am, or appman

[Vinfall]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

New comment by Vinfall on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2716333074

Comment:
I totally agree with you and appreciate your work.

It's just the conflict between out-of-box support (which is great!) and my (peculiar) preference to control everything (I have `~/.local/bin` on `$PATH` but do not export `$XDG_BIN_HOME` or `$BINPATH`) by hand. I also _manually_ export things like soar bin path or mise shims in my shell rc to avoid additional environment variables or plugins. This is personal and I don't think this way is better, it just fits _me_. Anyway, this is going off-topic as my point of commenting is suggesting soar as possible alternative instead of ranting on AM/appman.

Re: Package request: am, or appman

[Vinfall]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

New comment by Vinfall on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2716276125

Comment:
> even when using `appman` it will go beyond the XDG spec and check for `XDG_BIN_HOME` before defaulting to `$HOME/.local/bin`.

You are right, sorry for the false claim🙇. After looking at my notes, it was appman touching my shell rc and $PATH without notice that makes me mad. And it would download another script instead of installing itself to ~/.local/bin. ~~In my notes I also complain about bash-completion but I already forgot how it's dirty.~~

Re: Package request: am, or appman

[Samueru-sama]

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

New comment by Samueru-sama on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2716351410

Comment:
>  but do not export $XDG_BIN_HOME or $BINPATH

Those will only be added to the shellrc if we detect that `$BINDIR` is not in `PATH` when appman gets installed. 

`BINDIR` being `"${XDG_BIN_HOME:-$HOME/.local/bin}"`

In other words if you had already `$HOME/.local/bin` in `PATH` when you installed appman, it should not have touched your shellrc at all. 🤔

Anyways I also agree with you that soar might be a better alternative, specially because it is a single binary while AM has the whole modules thingy that get sourced. Rhino just runs the install script of AM during initial setup, it does not make an AM package xd.

Re: Package request: am, or appman

[Vinfall]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

New comment by Vinfall on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2716370791

Comment:
> In other words if you had already `$HOME/.local/bin` in PATH when you installed appman, it should not have touched your shellrc at all. 🤔

I guess that's because I split shell rc into different parts (PATH related ones mostly in `~/.profile`, but more zsh plugins are lazy-loaded and would modify `$PATH`). It's an edge case (and a bit hard for AM to detect that? 🤔) so I won't call it a bug.

Re: Package request: am, or appman

[zen0bit]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

New comment by zen0bit on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2717895025

Comment:
👍 
Don't need 32bit repo for Steam gaming anymore

Thanks to AM and Steam AppImage
Thanks to @ivan-hc and @Samueru-sama 

Re: Package request: am, or appman

[zen0bit]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

New comment by zen0bit on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2717895025

Comment:
👍 
Don't need 32bit repo (and non-free) for Steam gaming anymore

Thanks to AM and Steam AppImage
Thanks to @ivan-hc and @Samueru-sama 

Re: Package request: am, or appman

[zen0bit]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

New comment by zen0bit on void-packages repository

https://github.com/void-linux/void-packages/issues/54251#issuecomment-2717895025

Comment:
👍 
Don't need 32bit repo (and non-free) for Steam gaming anymore

Thanks to AM and Steam AppImage
Thanks to @ivan-hc and @Samueru-sama 

PS: Maybe I can get rid of glibc, and try to live in musl now?