Giter Site home page Giter Site logo

Comments (20)

Enderteck avatar Enderteck commented on June 13, 2024 1

Bro I just wanna package my game the normal way. It's the standard for Linux apps and games. If you don't know about Linux you can just say it.

from love.

MikuAuahDark avatar MikuAuahDark commented on June 13, 2024 1

From what I understand, standalone LOVE are not compatible with Flatpak sandboxing. Most people run LOVE by specifying the current project directory. Running .love file using Flatpak LOVE (assuming the mentioned one with permission issue) can be done with flatpak run --file-forwarding org.love2d.love2d @@ path/to/game.love @@. However you can't do the same for directories. Instead you need to use entirely different command-line which is (untested, may require root) flatpak run --filesystem=/absolute/dir/to/your/game org.love2d.love2d /absolute/dir/to/your/game. Before you ask, yes you have to specify your game directory twice.

If you don't like AppImage then sure. Feel free to dump the entire AppImage contents using --appimage-extract or any squashfs-symlink-capable extractor application and distribute that whole directory structure (starting from inside the squashfs-root) as .tar.gz. Every executable in the AppImage is compiled from source and patched to run anywhere regardless of the directory. With this, you can perform standard Windows fusing to the LOVE binary using cat bin/love your/game.love > bin/game && chmod +x bin/game. You can then repackage your game (as Flatpak) as you see fit. One of the flatpak member mentions that the LOVE Flatpak should be packaged as shared-modules to facilitate other games using it.

Now let's address the issues you mentioned in the discussion regarding AppImage:

No sandboxing

Again, standalone LOVE is not fully compatible with sandboxing as user expects the LOVE app to be able to access their project directory.

Doesn't solve the "run everywhere" problem, AppImages usually are compiled agaisnt Ubuntu LTS's, which isn't 100% binary compatible with other distros, e.g. fedora

Starting from 11.4, we no longer hear any issues regarding cross-distribution issue with the AppImage. People have been successfully run our AppImage in Fedora and ArchLinux. Assume the glibc version is compatible, then it should run. Of course there's problem for non-glibc distro but this can't be helped as AppImage itself only supports glibc-based mainstream distributions.

Its a game of bingo whether the AppImage has a library bundled or not, and whether the app will work your host version or not.

This is easy. Simply check them with ldd. If there are 3rd-party library loading from /usr or marked as "not-found" then it's not compiled correctly.

Performance, appimages are a compressed filesystem that getss mounted by fuse each time the app is run, which is slow, additionally subsequent launches of the app aren't even faster because we get fresh inodes each launch.

If this is really matters, you can extract the AppImage contents and run the underlying executable directly as I mentioned. Note that this is only guaranteed for LOVE AppImage starting from 11.4 though and may not work on all apps.

Bad system intergration, appimaged is an abomination.

This is only point where I agree, I guess.

AppImages promote a bad security practice of marking binaries from the web as executable, let's not replicate the main way malware is distributed on Windows.

Yeah if you run executable from shady sources then good luck. This is general issue with any OS, not limited to Windows. The best antivirus is common sense.

If you still insist on having LOVE as Flatpak, please let us know a strong reason for it.

Full disclosure: I author the 11.4+ AppImages.

from love.

radgeRayden avatar radgeRayden commented on June 13, 2024

Neither AppImages nor Flatpaks are particularly strong options for game distribution, although both are used on occasion. AppImages are the closest to the windows experience (and I think easier to integrate) so that's why it's offered as one of the options. Nothing stops you from packaging a native build inside a flatpak, however.
For distribution on Steam for example the recommended way would be to make use of their Pressure Vessel runtime with a native build.

I believe you can get the executable and libraries from extracting the AppImage as well.

from love.

slime73 avatar slime73 commented on June 13, 2024

It's not the modern standard.

WIll there be better packaging format supported such as Flatpak

What makes flatpak better than a fully extractable AppImage, in your opinion? Is it truly a modern standard for games?

from love.

Enderteck avatar Enderteck commented on June 13, 2024

It's more widely used,
it's way more modern,
it has an app store already.
It has better permissions management.
And it's made to be quickly packaged from a github repo to whatever distro you want.

from love.

slime73 avatar slime73 commented on June 13, 2024

it's way more modern

What does this mean for you as a user on a practical level?

It has better permissions management

What does this mean for you in practice? I know someone made a third party flatpak for LÖVE in the past and it didn't have enough permissions to find/run people's projects. Maybe it was a misconfiguration from the author but so far as a non-Linux user I've only seen the opposite of better (in practice) permissions, so I'm curious.

from love.

Enderteck avatar Enderteck commented on June 13, 2024

There seems to be an unofficial package on flathub because it's not listed on love.org and no flatpaks are released on github

https://flathub.org/apps/org.love2d.love2d

from love.

zorggn avatar zorggn commented on June 13, 2024

Yes, that's the one that has perms issues on at least steamdeck, since i did try using it and it did not load projects correctly, whereas the appimage worked flawlessly.

Also, linux and standards are two very laughably incompatible statements; by that logic, feel free to demand all your linux users to compile löve themselves and just release the packaged .love archives of your projects directly.

from love.

Enderteck avatar Enderteck commented on June 13, 2024

That why official Flatpak support is interesting. The point of having a flatpak release is to not have to package it. What do you mean.

from love.

slime73 avatar slime73 commented on June 13, 2024

I'm not your bro. :)

In general when someone wants to know more about a feature (like packaging a game) a good way is to ask in development discussion spaces. For LÖVE that would be the forums or discord server or subreddit. There you would hopefully have found out that you're already able to get the executable and its dependencies by extracting the appimage. The Game Distribution wiki page has steps for that as well.

Since you didn't do that and came here with feature requests instead, and some of those requests involve work for us and change for everyone else, it helps everyone to describe specifics about problems you ran into and how the changes you want solve those problems. Then we can evaluate what to do next. Sentences like "Having to use [x] is hell. It's not the modern standard." without explaining the actual problems you have does not help anyone. I still don't understand what's hellish because you haven't explained what you mean.

If developers unquestioningly implemented the whims of every person who barged into a bug tracker with a sort of "trust me bro I know best but you'll have to guess why" attitude, the results would not be pretty.

There seems to be an unofficial package on flathub

I believe that's the one with permission problems I mentioned earlier. Do you understand its problems enough to say whether an official one can work out of the box?

from love.

Enderteck avatar Enderteck commented on June 13, 2024

I'm not your bro. :)

Damn didn't know you weren't allowed to be friendly on here. Sorry if you felt misgendered though. I use it universally.

I didn't come here before looking at the discussions on the wiki and Github issues.
There were discussions on the wiki about stuff like that but the links all go to a now closed bitbucket repo:

https://love2d.org/forums/viewtopic.php?f=3&t=83087&start=20

https://love2d.org/forums/viewtopic.php?f=3&t=83208&p=206951#p206951

There is barely any info to distribute the game on anything other than an AppImage. There is experimental deb support but it's made by, and for debian only.

The only option right now as AppImage. It's bad in many ways and I don't want to list them all so here's a discussion about it:

AppImages Discussion

I know you can extract the appimage but the process of doing so is unnecessarily complicated and a waste of time. There isn't any documentation on how to even do that or if it's even safe.

Do you understand its problems enough to say whether an official one can work out of the box?

Yes, AFAIK an Official one can definitely work out of the box as a flatpak.

There are emulators, web browsers and there's even the unity game engine on Flathub.
Permission are getting screwed on the current Flathub package but it's not a Flatpak limitation, this is a problem with the current non official package on there, and an official release there is the way to go to fix the issue.
This is why I opened this issue.

I mean it's not normal that there needs to be an unofficial package on Flathub, it's not safe and I don't think there are löve experts.

from love.

slime73 avatar slime73 commented on June 13, 2024

I know you can extract the appimage but the process of doing so is unnecessarily complicated and a waste of time. There isn't any documentation on how to even do that or if it's even safe.

I don't understand, the wiki documentation page I linked earlier describes the single-line command to do that in the AppImage section. It's not as easy as automatic game packaging that large engines like Unity (or third party packaging tools like makelove) provide - but the same is true for all platforms love runs on right now: we don't have built-in packaging and we'd like to do that in a future version. There's already an issue in the tracker for that.

There is barely any info to distribute the game on anything other than an AppImage.

I think this is largely because most people are interested in distributing their Linux love games on services like Steam or with appimages or the unpacked standalone contents. A much smaller number of people have used flatpaks, the interest just hasn't been there comparatively.

an official release there is the way to go to fix the issue.
This is why I opened this issue.

Fixing an issue with a third party distribution isn't a very strong incentive on its own to take over distribution, for me. There are all sorts of third party distributions of love on Linux, if we maintained all of them ourselves we probably wouldn't have time for other aspects of development. Having fewer combinations of installs means fewer combinations of problems and less confusion when a user wants to pick what to use. Keeping an unpopular combination that needs maintenance is undesirable. Adding a new combination has to have pros that outweigh those cons.

I didn't come here before looking at the discussions on the wiki and Github issues.

I was saying you should've asked in a discussion forum since you missed the wiki documentation, because you would've got an answer to one of the questions you have in your issue post.

from love.

MikuAuahDark avatar MikuAuahDark commented on June 13, 2024

So, unless you have strong opinion on why we should add official Flatpak support, then this is not something we can keep maintain because our AppImage distribution proved itself to be sufficient. As for Snap, it has been rejected in the past.

from love.

Enderteck avatar Enderteck commented on June 13, 2024

So, unless you have strong opinion on why we should add official Flatpak support, then this is not something we can keep maintain because our AppImage distribution proved itself to be sufficient. As for Snap, it has been rejected in the past.

Having help in the Wiki to distribute a game on anything other than an appimage is a must though. I won't talk about the obvious flaws of it here, but just being able to download an archive of love without it being package as an AppImage is important, especailly for the many distributions where AppImages don't work (Not Fedora or Arch). Or anyone who wishes to use a more widespread, noob-friendly or modern solution.

I'm very sad to see that this Game framework won't be officially distributed on Flathub like most game engines.

Updating is also the biggest issue in my opinion. Having to redownload a whole appimage which is 100x bigger than a flatpak update is unnecessary.

from love.

MikuAuahDark avatar MikuAuahDark commented on June 13, 2024

If you have something to write in the game distribution wiki such as distributing for FlatPak, then feel free to add them into the wiki. If you have forum account you can use same credentials to login into the wiki.

Having to redownload a whole appimage which is 100x bigger than a flatpak update is unnecessary.

What is your definition on "big" here? If "big" by your definition is 5MB, then I have bad news for you. Also looking at https://flathub.org/apps/org.love2d.love2d, it's written that the install size is ~10MB, whilst our AppImage is barely 5MB. The Flatpak download size is ~4.7MB which is close to our AppImage. Plus point for our AppImage because no install is necessary.

I'm very sad to see that this Game framework won't be officially distributed on Flathub like most game engines.

Well, one step to get LOVE officially as Flatpak is to contact whoever maintain https://flathub.org/apps/org.love2d.love2d to get in contact with us to discuss about it.

but just being able to download an archive of love without it being package as an AppImage is important, especailly for the many distributions where AppImages don't work

In which case you can run love.AppImage --appimage-extract and run the underlying bin/love executable directly. This will increase the size to ~10MB though, again, on par with the Flatpak install size.

from love.

JakobDev avatar JakobDev commented on June 13, 2024

I'm the maintainer of the Flatak. I was pointed to this Issue.

Most people run LOVE by specifying the current project directory.

The Flatpak was primarily made to open .love files. It also ships with the official desktop file which has only support for the .love files and not directories. I can however add read only permission for the full host system, if you want, but that will lower the security rating.

Instead you need to use entirely different command-line which is (untested, may require root) flatpak run --filesystem=/absolute/dir/to/your/game org.love2d.love2d /absolute/dir/to/your/game. Before you ask, yes you have to specify your game directory twice.

You could just use a tool like Flatseal to permanently set a Permission for a Flatpak instead of setting the Permission in the command each time you run it. You also don't need root.

Well, one step to get LOVE officially as Flatpak is to contact whoever maintain https://flathub.org/apps/org.love2d.love2d to get in contact with us to discuss about it.

If want to official maintain the Flatpak, I can ask the Flatpak Team to transfer it to you.

I mean it's not normal that there needs to be an unofficial package

Unofficial packages are very common in Linux.

it's not safe

It's Sandboxed, so it's safer than other installation methods.

The point of having a flatpak release is to not have to package it.

Unlike other package formats, Flatpak don't really have a dependency System. You still need to package it yourself. You can however just copy and extend the existing manifest.

If you any other questions, just ask.

from love.

MikuAuahDark avatar MikuAuahDark commented on June 13, 2024

Thank you for getting in touch with us.

The Flatpak was primarily made to open .love files.

I see. Perhaps it could be made clear in the description that it can't open arbitrary directory?

I can however add read only permission for the full host system, if you want, but that will lower the security rating.

Right. A trade-off has to be taken between user convenience or Flatpak security. Allowing full host system access defeats the purpose of Flatpak sandboxing.

If want to official maintain the Flatpak, I can ask the Flatpak Team to transfer it to you.

Thanks, but I think it's not necessary because we're laking Linux maintainers. Currently our active maintainers are slime73 which maintains macOS, iOS, and Windows platforms, me which maintains Windows (at some extent), Linux (at some extent; through WSL2) and Android platforms, and semi-active bartbes which maintains the Linux platform.

We could probably discuss it internally if we can endorse your Flatpak as our official Flatpak though. If this happends, all we ask is to ensure changes in upstream doesn't affect your ability to build the Flatpaks. You also feel free to send improvements if you think it makes it easier for you to build the Flatpaks. You can get contact with us in our Discord server (preferred; most active; fastest response) or through any other channels.

That being said, perhaps you may want to consider this? flathub/flathub#2686 (comment) I'm not too fond with the technicalities of Flatpak so pardon me if I'm writing nonsense.

from love.

Enderteck avatar Enderteck commented on June 13, 2024

Right. A trade-off has to be taken between user convenience or Flatpak security. Allowing full host system access defeats the purpose of Flatpak sandboxing.

I use many flatpak apps that only access the drectories I open with them and Flatpak would make user convienience and security higher, it's not a trade-off.

I see. Perhaps it could be made clear in the description that it can't open arbitrary directory?

That can be fixed though and it doesn't make sense to ship a partially working love version on Flathub, especially since it's the primary way of installing apps on most distros (after packages but they aren't universal).

I mean it's not normal that there needs to be an unofficial package

Unofficial packages are very common in Linux.

Obviously it's very common but it's because the Programs that refuse to be on Flathub are already packaging their apps for most distros. Löve is only being packaged for Ubuntu which is the only distro without Flatpak out of the box. Even Debian comes out of the box with Flatpak support.
An Ubunut PPA + Flatpak would cover every distro under the sun, even better than the AppImage can. (or just support flatpak and tell ubuntu users to install it)

Even if the löve package didn't use sandboxing it's better than an AppImage in every way.

flathub/flathub#2686 (comment)
This is probably the solution, make a flatpak shared module so that flatpak löve games can just install that instead of having to bundle everything themselves.

Most Open source programs already moved to Flathub with even bigger limitations than this. Example: OBS, Gimp, Visual Studio, Blender, Unity hub, etc.

Even non-Open source options are on Flathub as it's the future of App distribution on Linux.

from love.

JakobDev avatar JakobDev commented on June 13, 2024

I will add read only host permission to the Flatpak. That would help Users and there it does not do much harm, as it's read only.

me which maintains Windows (at some extent), Linux (at some extent; through WSL2) and Android platforms, and semi-active bartbes which maintains the Linux platform.

I could request write access for you, if I you want. The build files are inside this GitHub repo, so I could request access for you.

ensure changes in upstream doesn't affect your ability to build the Flatpaks

As long as it build on Ubuntu, it should also build on Flatpak

You also feel free to send improvements if you think it makes it easier for you to build the Flatpaks.

The is nothing specific for Flatpak, but it would be great if you would name your desktop and icon files org.love2d.love instead of just love. This is a common naming convention in Linux and I would no longer need to rename the files. You could also upstream the ApStream file.

This is probably the solution, make a flatpak shared module so that flatpak löve games can just install that instead of having to bundle everything themselves.

You completely misunderstood shared modules. You will still need to build and bundle love. Using shared modules is basically the same as copy the build instruction in your Manifest. A module also needs to be used by many before it can be added to the shared modules repository. That's currently not the case for Love2d.

from love.

MikuAuahDark avatar MikuAuahDark commented on June 13, 2024

but it would be great if you would name your desktop and icon files org.love2d.love instead of just love.

Would it be possible to have the Flatpak package ID renamed to org.love2d.love too, for consistency? Or is it too late?

I will add flathub/org.love2d.love2d#7 to the Flatpak. That would help Users and there it does not do much harm, as it's read only.

Thank you. This should at least helps unsuspecting users.

from love.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.