Packaging for linux - what's best practice?

sausagesausage
edited January 2015 in General discussions
I've got my game ready in a folder for linux, but what is the generally accepted way to package a game?

Currently I have the following structure:
beanfarmerpinball/
   data/
   liborx.so
   packed.ini
   pinball (executable)
   pinball.ini

I could just zip that up and submit it to a game repository. But does anyone package an .rpm or .deb for games even though it reduces the flavours that could run it?

Also, a "readelf -d pinball" shows the following dependencies:

0x00000001 (NEEDED) Shared library: [liborx.so]
0x00000001 (NEEDED) Shared library: [libdl.so.2]
0x00000001 (NEEDED) Shared library: [librt.so.1]
0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x00000001 (NEEDED) Shared library: libpthread.so.0]

Should I ship those .so libraries with my game and assume that the user may not have it on their system? liborx.so is a given of course.

Comments

  • lydesiklydesik
    edited January 2015
    why not build and link against the static lib (liborx.a) ?
  • KnolanKnolan
    edited January 2015
    Depends how you want to distribute it.

    You can create a package with dependecies, linux will automatically install the dependencies (assuming they are in a public repository).

    As Lydesik said, you can also link it staticly, but this will inflate the size of you executable.

    Finally, you can distribute the so files and use -wl,rpath gcc option to specify that the executable must use the distributed so files.

    PS: keep in mind that if you want to link the libraries yourself you will need to build one for 32 bits and one 64 bits.
  • iarwainiarwain
    edited January 2015
    Using the static version of orx wouldn't really solve anything about the dependencies unless you recompile them manually yourself statically as well.

    In addition to becoming a huge pain in the ass, you'll also encounter some issue with licenses as some dependencies, such as libsndfile, are licensed under LGPL.

    Packaging your game as a .deb, .rpm or whatnot might be the best approach but I find the process to be needlessly complicated and I decided not to bother with it myself.
  • sausagesausage
    edited January 2015
    lydesik wrote:
    why not build and link against the static lib (liborx.a) ?

    Thanks. I thought that linking against the static liborx would build in that library but not ones that itself depended on.

    I'll give it a go.
  • iarwainiarwain
    edited January 2015
    And I believe you're right. :)
  • sausagesausage
    edited January 2015
    iarwain wrote:
    Using the static version of orx wouldn't really solve anything about the dependencies unless you recompile them manually yourself statically as well.

    In addition to becoming a huge pain in the ass, you'll also encounter some issue with licenses as some dependencies, such as libsndfile, are licensed under LGPL.

    Packaging your game as a .deb, .rpm or whatnot might be the best approach but I find the process to be needlessly complicated and I decided not to bother with it myself.

    *Sigh* :( Linux shoots itself in the foot. Maybe I just rpm/deb it.


    But thanks everyone for the input.
  • KnolanKnolan
    edited January 2015
    Actually, you will have the same issues with windows, if the user does not have the libraries.

    The advantage of package is that a RPM (or a deb) file with the right dependecies configuration will automatically solve them, AFAIK windows has nothing even similar to that.
  • iarwainiarwain
    edited January 2015
    Generally speaking, yes. That's why most, if not all, applications ship with all their dependencies packaged with them.
    In the case of orx though all the dependencies will be compiled statically, including the C/C++ runtime, as it's an option offered by the system.
  • daltomidaltomi
    edited February 2015
    Hi,

    I am a maintainer of this game engine for Archlinux, unofficial, but Arch User Repository (AUR).
    https://aur.archlinux.org/packages/orx/

    The dependencies for liborx.so are: http://termbin.com/jxi5

    So far there are 3: libsndfile, mesa-libgl, openal (in Arch)

    If you want you can create a AUR package for your game.
    It is installed in one of several ways: yaourt -S your_game, packaur -S your_game, etc.

    You must provide support for different architectures: i686, x86_64, or both.
    It is also necessary md5 hash, but I'll take care of that.
    You should only provide an archive with all the game, the file PKGBUILD is responsible for copying every file in place in the system.
    Your game depend on orx AUR package, which installs the game engine (liborx.so, etc).

    By default, data for games installed in /usr/share/games/your_game/
    If you can make your game look their data in that direction, it would be best.

    If you want to try the experiment, I help :)

    Sorry for my bad english.
  • iarwainiarwain
    edited February 2015
    Hi daltomi and welcome here!

    Thanks for your intervention. :)

    It's nice to see orx being maintained for one of the big distro out there!

    I'll try to install a Archlinux box in a few days and will try what you suggested, I have zero experience with making any linux-related package and I wasn't sure where to start.

    In the end, if we can provide a step-by-step guide on the wiki, I'm sure it'll be beneficial to everyone. :)
Sign In or Register to comment.