games-util/Steam-appimage: new package, add 1.0.0

[vitaly-zdanevich]

@ivan-hc
@Samueru-sama

[antecrescent]

I don't really see the point of adding this package to ::guru, when there's games-util/steam-launcher in ::steam-overlay. I'd like to remind you[1] that packages you contribute to GURU should be useful to others as well. An AppImage of Steam inside of an Arch Linux container is just too niche in my opinion.. I'm not going to merge this, sorry.

If you're looking for an all-in-one solution, maybe check out: https://wiki.gentoo.org/wiki/Steam#Flatpak?
[1]: https://bugs.gentoo.org/927922

[Samueru-sama]

I don't really see the point of adding this package to ::guru, when there's games-util/steam-launcher in ::steam-overlay. I'd like to remind you[1] that packages you contribute to GURU should be useful to others as well. An AppImage of Steam inside of an Arch Linux container is just too niche in my opinion.. I'm not going to merge this, sorry.

If you're looking for an all-in-one solution, maybe check out: https://wiki.gentoo.org/wiki/Steam#Flatpak? [1]: https://bugs.gentoo.org/927922

Hello, I'm one of the people that keep the steam appimage, the good thing of the appimage is that it is actually an all in one solution, all you need is the appimage, nothing else. We also provide fixes like the steam-screensaver-fix and the patched EAC-Glibc in the appimage.

The steam flatpak isn't really a all in one solution since you need to install flatpak on the system.

With that said, there is one limitation in Gentoo right now, since the appimage uses the static runtime (the appimage doesn't depend on libfuse2) it has a bug on gentoo that means that the FUSERMOUNT_PROG env variable needs to be defined beforehand.

[vitaly-zdanevich]

I don't really see the point of adding this package to ::guru, when there's games-util/steam-launcher in ::steam-overlay.

Is it working on no-multilib profile?

And here we need only one dep - fuse.

[vitaly-zdanevich]

The steam flatpak isn't really a all in one solution since you need to install flatpak on the system.

...and have a daemon always working in the background.

[vitaly-zdanevich]

If you're looking for an all-in-one solution, maybe check out: https://wiki.gentoo.org/wiki/Steam

Quote from the link:

Steam provides 32-bit environment for most of supported games, so client itself requires a multilib profile on amd64

[stkw0]

I am unsure how the LICENSE should be listed if it's an oll-in-one solution. For Go or Rust packages for example all licenses of the bundled libraries also appears in the LICENSE variable.
Following the same logic, I assume that it should appear all the license of all programs and libraries included in the container, which doesn't sound something feasible.

[justin025]

I'm not sure what guru's policy is on appimages, but wouldn't it make more sense to extract the appimage to /opt and drop fuse as a dependency?

[ivan-hc]

I am unsure how the LICENSE should be listed if it's an oll-in-one solution. For Go or Rust packages for example all licenses of the bundled libraries also appears in the LICENSE variable. Following the same logic, I assume that it should appear all the license of all programs and libraries included in the container, which doesn't sound something feasible.

Being this an AppImage containing a portable Arch Linux container, all licenses of each internal program are placed where are placed if installed normally wia Arch Linux.

You can check the content in two ways:

• easier way is to launche tha AppImage and check the content of the internal file system of the container, at /tmp/conty_*/mnt (here you will see the full structure)
• extract the AppImage and the internal conty.sh file, like this:

./*.AppImage --appimage-extract
cd squashfs-root
./conty.sh -e
cd conty.sh_files

[vitaly-zdanevich]

I'm not sure what guru's policy is on appimages, but wouldn't it make more sense to extract the appimage to /opt and drop fuse as a dependency?

This is interesting - no dependencies, and faster start? But more size on the disk?

But useful property of AppImage - that you can copy only one single file to USB or send to a friend - Steam profile and user data stored in home directory.

[stkw0]

all licenses of each internal program are placed where are placed if installed normally wia Arch Linux

This will not make it. Arch seems to have a more relaxed policy than Gentoo in this regard, so it can not be trusted. Maybe someone more experienced can comment on this, but it doesn't seem that simple.

Another option is to package the scripts though, but it breaks the purpose of the program, or at least doesn't offer an advantage over flatpak.

[eli-schwartz]

all licenses of each internal program are placed where are placed if installed normally wia Arch Linux

This will not make it. Arch seems to have a more relaxed policy than Gentoo in this regard, so it can not be trusted. Maybe someone more experienced can comment on this, but it doesn't seem that simple.

Arch's metadata format supports multiple licenses, just like gentoo's does. Individual package maintainers would have to take advantage of that feature though, which most do not. Typically what you'll see is a single license, the primary one, with the rest ignored.

This is readily visible in the rust and golang ecosystems, where packages will list the license of the main crate whereas e.g. pycargoebuild walks the license tree and updates the full license list for you. More importantly, Gentoo culture actually places a high priority on demanding to hear that the licenses field is properly calculated -- Arch does not.

Many Arch packages use the license "custom" because it's not included in the global licenses set and in such cases the package itself will install a license file to /use/share/licenses/${PN}:${SLOT}/* (or rather the equivalent which on arch is just ${pkgname} -- no slotting.

This is usually the upstream COPYING file or somesuch -- which is as accurate as upstream makes it be, that being anywhere from "very accurate" to "the license changed 4 years ago but they forgot to update the COPYING file and only modified the per-source-file license comments".

[vitaly-zdanevich]

@ivan-hc according to Gentoo IRC communication - they want to list all deps licenses:

11:22:47 PM - stkw0: negril: what do you think about the licensing part (being this appimage a container)? I think you had more experience in that topic.
11:23:27 PM - negril: That appimage is basically gl
11:23:41 PM - negril: So it's fine in your local repo, not in ::guru
11:23:59 PM - negril: You'd have to list _everything_ in the appimage
11:42:14 PM - vitaly-zdanevich: negril: what is gl?
11:42:44 PM - negril: good luck
11:43:05 PM - vitaly-zdanevich: negril: why this is bad for Guru? Steam is a high-profile software - and this appImage - the only way to run Steam on no-multilib
11:43:30 PM - negril: Because the license doesn't allow us to
11:43:36 PM - vitaly-zdanevich: What license?
11:43:45 PM - negril: Of anything that is distributed
11:43:46 PM - vitaly-zdanevich: The license of what part?
11:43:53 PM - vitaly-zdanevich: Why??
11:44:09 PM - negril: Because you can't even correctly specify the license
11:44:44 PM - vitaly-zdanevich: We can specify the license of all used projects
11:45:25 PM - ztrawhcse: simply list every license in the repository licenses/ directory

https://github.com/gentoo/guru/tree/master/licenses

Can you please do it? It will also be useful for packaging for other Linux distributions.

[negril]

Relevant quote:
11:23:41 PM - negril: So it's fine in your local repo, not in ::guru

[vitaly-zdanevich]

@ivan-hc they do not like AppImage ebuilds because this is one file - too simple :)

What do you think about the ebuild that builds Conty? As I understand - your repo is only Conty inside AppImage?

And I can add USE flags - so can we make it configurable? For example I have no nvidia - so we can drop it.

[JohnMH]

Similar to conty, this is just another distribution in a file. I'm not sure that's a good fit for GURU. The general idea is to provide packages for installation in Gentoo, not to provide other distributions as a package.

[vitaly-zdanevich]

It packs a lot of useful software to run games. The main one - Steam.

[negril]

Then put it on your own overlay.

[vitaly-zdanevich]

But I want to help other users too.

[negril]

Then make your overlay publically available. But this as no place in ::guru.

[ceamac]

Looks like nobody wants to merge this one, so I'll close it.