Godot: Why Godot isn't in Debian repository

[terater]

Operating system or device - Godot version: Linux

Issue description:

Why Godot Engine isn't in Debian repository ? It could be more useful when making upgrade to newest version of Godot.

[nunodonato]

Doesn't that depend on Debian's package maintainers?

[akien-mga]

Because no Debian packager tried to package it so far.

Godot is in repositories for Mageia, Arch, FreeBSD, ROSA, soon Fedora and maybe openSUSE. https://repology.org/metapackage/godot/versions
For Debian the barrier to entry is much higher, it needs a motivated Debian maintainer.

[nunodonato]

@akien-mga speaking of which, maybe it would be good to have Godot in flatpak or appimage?

[punto-]

I think one of the distros had a problem with some of the binaries in the
template package, because they couldn't be built with tools available on
the distro itself? (probably osx and ios)

On 29 May 2017 at 12:26, Nuno Donato [e-mail] wrote:

@akien-mga https://github.com/akien-mga speaking of which, maybe it
would be good to have Godot in flatpak or appimage?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/8983#issuecomment-304686693,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGVmPTN9nOhLUDuaQxejY1MfEfEkIOxTks5r-uO2gaJpZM4NpbLN
.

[akien-mga]

Well Linux distros don't need to build the OSX and iOS templates, they can just ship the editor and let users download our templates.

[probonopd]

@nunodonato

speaking of which, maybe it would be good to have Godot in flatpak or appimage?

Check out

• https://archive.hugo.pro/godot/
• https://godotdevelopers.org/forum/discussion/17690/testing-welcome-appimages-for-a-portable-godot-editor
• https://github.com/godotengine/godot/issues/6681
• https://bintray.com/probono/AppImages/Godot#files

[eon-s]

Snap packages could be good too

[DriNeo]

It is possible to create a .deb package anyway ? The goal would be to obtain a clean installation automatically.

[akien-mga]

I'm not fond of upstream provided packages, when you install stuff from outside your distro's package manager, I think it better to let users install in their $HOME or mess themselves with their /usr system. I've already had distro upgrade issues due to thirdparty packages (thinking of you early Humble Bundle RPMs), it's not pretty.

What would be more interesting would be to get Godot packaged in PlayDeb: http://www.playdeb.net/welcome/
The main packager there is relatively reactive, so you can file a packaging request and see what happens. I'd gladly give a hand to make sure it's packaged properly.

[probonopd]

I've already had distro upgrade issues due to thirdparty packages (thinking of you early Humble Bundle RPMs), it's not pretty.

You are guaranteed __not__ to get such issues with AppImage , since it does __not__ touch your system and does __not__ interfere with the package manager of your base system.

Providing an AppImage would have, among others, these advantages:

• Works for most Linux distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions

[DriNeo]

@akien-mga I wonder how a Godot installation script can break something in a Debian distro since Godot have no dependencies to look for. My custom installation just needs an "usr/local/bin" folder for the Godot binary and a "usr/share/application" for the desktop file. The icon can be stored into the common Debian folder who stores application icons. If we use the generic Linux folders how we can break something ?
Of course I can be wrong, I'm a Linux noob.

[ghost]

@probonopd So you package a single executable binary in app image to make a single executable binary. Makes sense.

[probonopd]

@ArcFutahito yes, along with all icons, documentation, libraries, and any other resources the app might need.

[Calinou]

@ArcFutahito AppImages have other benefits that statically-linked binaries don't have, such as compression, single-file GPG signing (no additonal files required), and being able to still dynamically link some libraries (like OpenSSL).

[QuLogic]

One of the major reasons why Godot likely isn't in official Debian (and definitely Fedora) repos is the immense number of bundled and patched packages. @akien-mga did a tremendous amount of work in #6830 to correct this, but there's still a little ways to go there.

[akien-mga]

@QuLogic That's incorrect. All libraries which are packaged in Debian, Fedora or other Linux distros can be easily unbundled and are unpatched. The few patches we have are usually for platform support (e.g. UWP for OpenSSL) and when building on Linux, it's not an issue to discard those changes.

As a Fedora packager, I can tell you that if Godot is not in the repos yet it's just because I haven't had the time to work on it. (And no other packager seems to have expressed interested in it). I also wanted to finish my work on the COPYRIGHT.txt file which should ease licensing review for Linux distros.

As for Debian, it's sadly the normal inertia of that (great, but slow) distro. For example it took me 9 months to get the new version of OSS Lugaru packaged in Debian, while they already shipped an earlier buggy and partially non-DFSG-free version of it and the new version is basically just cmake && make && make install and everything is perfect packaging-wise.

[QuLogic]

Sorry, I should have prefixed that with a "Historically". Things have changed with your work of course, and Fedora is a little bit laxer with regards to bundling as well. I was looking into it myself, and I think there may be one or two more things that could build against the system that are not yet configurable in that way. Anyway, if you attempt to package for Fedora some time soon, ping me and I'll try to review it for you.

[akien-mga]

I was looking into it myself, and I think there may be one or two more things that could build against the system that are not yet configurable in that way.

Please file issues about those, everything that can be unbundled should be.

Anyway, if you attempt to package for Fedora some time soon, ping me and I'll try to review it for you.

It would likely be similar to my Mageia package: http://svnweb.mageia.org/packages/cauldron/godot/current/SPECS/godot.spec?view=markup
Dependency-wise it's a bit tricky as Godot 2.1.x does not support OpenSSL 1.1+ yet, nor GCC 6+, so we need to build against compat-openssl10 and llvm. Will see on review if the former is an issue for a new package.

[akien-mga]

@QuLogic Here's a (yet untested, need to fire up my Fedora VM) PoC spec file for Fedora/RHEL based on my Mageia package: https://gitlab.com/snippets/1676357

For the License tag, if it's required I would still need to go through COPYRIGHT.txt and add all the licenses of the not-unbundled code snippets and small libraries. BTW I chose not to patch COPYRIGHT.txt even though many of the libraries it references are unbundled, because it's also the data which is displayed in Godot's About window, and when users download statically linked templates from our website, they still need to be aware about the stuff it includes.

And the diff between the Mageia package and the Fedora edits: https://hastebin.com/yolupecefi.diff

[so-rose]

Apparently somebody was going very strong on packaging 2.1.4, before stopping suddenly about a month ago (date of last commit was Dec 31st, 2017 as of writing) - perhaps waiting for 3.0.0? Except 3.0.0 has been out for over 2 weeks...

Debian ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793057
Built Package: https://mentors.debian.net/package/godot
Git Repo: https://github.com/kienanstewart/godot/tree/2.1.4-stable-debian

It looks quite complete (besides mono, only libxi seems to be added, and the libssl seems to be taken care of). I'll try to take a look at it myself, though my Debian packaging experience isn't exactly encompassing!

@akien-mga I think a Debian package would currently have to build Godot without C# support, as the newest mono in Debian is still at version 4.6 in Dec. 2016 - way too old. See this: https://tracker.debian.org/pkg/mono . Any ideas?

[akien-mga]

I think a Debian package would currently have to build Godot without C# support, as the newest mono in Debian is still at version 4.6 in Dec. 2016 - way too old. See this: https://tracker.debian.org/pkg/mono . Any ideas?

I think that's fine, I also build Godot without C# support on Mageia and Fedora, and expect most distros to do the same. Mono support implies very strong requirements on the SDK version (right now it needs to be the exact same one as used to build the official binaries), so once we provide export templates, I think people should only use official editor binaries for C# support (where we'll likely eventually bundle the relevant parts of the SDK).

[akien-mga]

Closing as this is very much a downstream issue. If Debian maintainers have issues to raise regarding packaging, feel free to open new tickets.

[akien-mga]

Seems like Godot is about to land in Debian eventually: https://ftp-master.debian.org/new/godot_3.0.6-1.html

[swenner]

Godot is in Debian testing and unstable! https://tracker.debian.org/pkg/godot

[FedericoCeratto]

Package maintainer here. The packaging is maintained at https://salsa.debian.org/debian/godot3/tree/master/debian Testing, patches and feedback on the package are very welcome.