Create Linux packages for download on website...

[datahead8888]

We were recently asked in IRC if we had Linux executables for download. I don't think all Linux users want to download from source. We ought to consider making Linux executables available for common variants of Linux such as Ubuntu, Debian, etc.

We also might consider coordinating this with our efforts to get TSC into other Linux distributions. Perhaps users can then test these installation packages for us after downloading them from our website? Keep in mind release 2.0 has been reported to repeatedly crash and can thus be viewed as unstable; we may not want to submit this version to any repositories.

@akien-mga and @muammar, any help is appreciated.

[refi64]

This is more complicated than it sounds, since different Linux distros tend to shove shared libraries in different locations...

[datahead8888]

Creating different installation packages for Linux repositories takes a lot of work in general, but we need this to get the game in front of people. It would be useful, however, to start posting these packages on our website for now for usage and evaluation. It will also make it easier on users who aren't comfortable with building by source.

Has static linking been considered in the past?

Am 06.10.2015 um 00:34 schrieb Ryan Gonzalez:

This is more complicated than it sounds, since different Linux distros
tend to shove shared libraries in different locations...

—
Reply to this email directly or view it on GitHub
#459 (comment).

[akien-mga]

As a distro packagers, I'm not really fond of third-party packages, as they are pretty hard to get right regarding the names of dependencies, etc., or the install locations that would be expected on the target systems (it's OK for Debian/Ubuntu which are quite similar, but sadly the RPM distros use different naming conventions for their libraries). Also a binary package built against a given shared library would likely only work against it, and thus would complain if one installs the package on a distro where this library has a different soname (e.g. new major version).

A better solution IMO is to simply create an executable with an RPATH (relative library path), and to copy the buildsystem's relevant shared libraries in the given RPATH, e.g. "./lib". This way you can produce a tarball which can easily be run on any Linux system, provided they have a glibc version at least as high as the one you built the binary with (i.e. it's best to build binaries on a not cutting-edge distro).

I'm making such binaries for @OpenDungeons and @ValyriaTear, I could probably have a look at it for TSC. This is for example the script I'm using to generate OpenDungeons binaries (I might have a slightly enhanced version in my local chroot):
https://github.com/OpenDungeons/OpenDungeons/blob/development/tools/portable/build-portable-binary.sh
And the resulting so-called "portable binary": http://download.tuxfamily.org/opendungeons/0.6.0/OpenDungeons-0.6.0-Linux64.tar.bz2

Has static linking been considered in the past?

I'm too fond of static linking personally, as it makes huge binaries, and if something is buggy in a library, then everything is buggy. With bundled shared libraries you can e.g. remove some of the libraries if you have them already on your system, and you know/think that your system's ones would behave better.

Keep in mind release 2.0 has been reported to repeatedly crash and can thus be viewed as unstable; we may not want to submit this version to any repositories.

Oops! It's on Mageia Cauldron (the future Mageia 6) already ;) The final release won't be before April 2016 though, so there's some time to backport fixes or have a patch release of TSC before that I guess.

[datahead8888]

As a distro packagers, I'm not really fond of third-party packages

In this context, what do you mean by a third party package? Do you think it's feasible to have the same type of installation format per Linux distribution on both our website and (eventually) the corresponding Linux application repositories? This would allow beta testers to test submissions to the Linux repositories by downloading them from our website.

[akien-mga]

In this context, what do you mean by a third party package? Do you think it's feasible to have the same type of installation format per Linux distribution on both our website and (eventually) the corresponding Linux application repositories? This would allow beta testers to test submissions to the Linux repositories by downloading them from our website.

By third party package I mean RPM and DEB packages which have been created by upstream (TSC) and not by the target distro packagers. Those packages usually don't respect all packaging policies of the target platform (as it's virtually impossible to handle this properly).

What I propose is more a simple tarball that the players would unarchive in their home directory and play from there, no installation involved. For those who really want a system-wide installation, we could of course provide a basic "make install" target, but I think it's best not to install third-party binaries system-wide anyway.

Note that Ubuntu users seem quite used to their PPA repositories, so that could be a possibility if you want to produce DEB packages for Ubuntu.

[datahead8888]

If it is the responsibility of the target distro packagers to make the packages and test them, you are correct there is no point posting packages for people to test on our website. The simplest solution for installation is thus preferable.

Also, regarding the crash bug, I was only making a suggestion about not publishing to (other) Linux repositories yet. This needs to be decided by the team as a whole.

[datahead8888]

cc @AMDmi3

[Luiji]

My advice for creating a third-party package is putting everything we need into /opt/tsc/<version> with the exception of a desktop shortcut installed into /usr/share/applications. Of course, if we did it right, TSC could be installed anywhere on the system and we could provide a nice shell script installer to ask people where they want it installed, or if they just want to extract it in the current directory, etc.

The only case I'd consider static linking is if we had complete ZIPfile virtual file system support, since we could append it to the end of the static TSC executable and create a single program that can just be run immediately.

Also, I'd consider including a LibC in our package, too, since sometimes there are Glibc incompatibilities between distros (Debian tends to have an older version, and consider distros like Alpine which use an entirely different LibC). I'd recommend a reduced one like musl so long as TSC's dependencies don't require functions musl doesn't have.

[AMDmi3]

I'm strictly against any third party packages. As upstream, you'll waste precious time, only cover a small subset of target systems, and the resulting package will still have quite high probability of breaking on specific distros or new versions thereof. As a user, I'll never run untrusted binary code myself, and I also don't want unreliable product which could break with the next system update (also nobody makes *BSD packages anyway).

You, as any F/OSS project, should target official repos. I can speak for FreeBSD, and as I remember the only thing which prevented FreeBSD port was that the project used outdated version of cegui. Is this still an issue? I haven't found any indication of that problem being resolved in #10.

[akien-mga]

I'm strictly against any third party packages. As upstream, you'll waste precious time, only cover a small subset of target systems, and the resulting package will still have quite high probability of breaking on specific distros or new versions thereof.

Same here. I think my proposal to make binaries with bundled shared libraries in a RPATH, with everything in a tarball to be used directly in the user $HOME, would be a good compromise. It's still third party binary code of course, so users should use it at their own risk; but in the case of TSC having to build CEGUI 0.7.9 really makes it hard for end users to build from source themselves.

So I think the way to go is contacting downstream packagers to let them know about the new release, and provide an upstream "portable" tarball with embedded shared libraries. And not with an embedded libc as suggested above, that would be far from easy. Bundling libc probably means bundling MesaGL and other core components that you would normally leave out so that the user's libraries are used instead.

as I remember the only thing which prevented FreeBSD port was that the project used outdated version of cegui. Is this still an issue?

As of 2.0 this is still the case yes, there is a possibility to let the TSC buildsystem build an embedded copy of cegui 0.7.9 if need be and link it statically I guess. For Mageia I've kept the old cegui in a cegui0.7 package. Looking forward to a next release that would remove the dependency or upgrade it to 0.8.x :)

[datahead8888]

I haven't found any indication of that problem being resolved in #10.

Quintus, to my recollection, found a bug in CEGUI itself that was blocking this upgrade at the time (radians / degrees issues if I remember right). We have seriously talked about the possibility of migrating to SFGUI as an API instead of using CEGUI. That choice isn't possible without SFML being in place, which SFGUI requires. Thus the decision was made to do the SFML port first (which resolves legacy SDL/OpenGL issues anyways) and then make a decision on CEGUI versus SFGUI at that time. Hopefully the CEGUI bug will be fixed by then, allowing an unbiased decision.

By the way, we're talking about locking down devel (at least with respect to features) until that SFML port is done. Come join the discussion at: http://forum.secretchronicles.de/topics/310