Comments (20)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
but it would be great if you would name your desktop and icon files
org.love2d.love
instead of justlove
.
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)
- Request: Love2D Android app ability to import and store .love files in its own directory (similar to iOS version) HOT 6
- Feature request: love.filesystem.newTempFile HOT 7
- Bug: File:read() returns empty string instead of nil when past end of file HOT 2
- Low FPS on certain monitor HOT 6
- love.data.compress causes a segfault on macOS Big Sur (LOVE 11.5) HOT 9
- Regression 11.5: key events not triggered when an IME language is active (windows) HOT 12
- [12.0] C++ exception with newShader() and Vulkan renderer
- (Android/IOS) Display rotation control HOT 1
- Brew install fails on macOS with: Error : SHA256 mismatch HOT 1
- Mouse is not updating on right / bottom screen edge (DPI scale > 100%) HOT 7
- Add a way to get Video duration
- Android Depth Buffer HOT 2
- remove the arbitrary 10x near/far plane scaling in the default projection matrix HOT 12
- Improve documentation about the window's depth buffer HOT 2
- Feature request: more performant anti-aliasing. Like FXAA or TAA. HOT 3
- Depth writes not writing to set mipmap HOT 2
- t.window.resizble = false doesn't work on android with LOVE 12 HOT 5
- Documentation: optional didactic "Implementation Details" section HOT 12
- symbol not found in flat namespace (___PHYSFS_platformCalcBaseDir) HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from love.