As an exercise in learning Solus's packaging tools, I decided to try building a package for Heroic Games Launcher. However, I'm learning that things are complicated! I need a bit of help.

So Heroic Games Launcher (hereon referred to as Heroic, because that's a lot to type) is an electron app, which means it mostly consists of JavaScript and CSS. The normal installation uses Yarn to collect dependencies and build/run the app. In addition to this being my first time working with Solbuild, this is also my first time working with Yarn.

The normal build process for Heroic seems to be a) have Yarn download any dependencies, and b) have Yarn package the app in the desired format. Out of the box they support quite a few formats but (unsurprisingly) not eopkg. I've started putting together a package.yml for this, but my issue is that Yarn can't download dependencies in the offline build environment that Solus uses. See my repository to tell me what I'm doing wrong.

  • Does anyone have experience packaging apps that typically use Yarn?
  • How do I go about collecting dependencies without being online? Do I need to work around Yarn and collect the dependencies myself, or is there a way to compile the eopkg online that will fit within Solus's packaging requirements?

Harvey Thanks for the tip. Now that you mention it, I should have seen this on the Package.yml page.

My question now is: How do I compile this collection of .js and .css files into an eopkg?

I have read somewhere that electron apps are generally frowned upon in Solus. If anyone has any experience working with electron and what infrastructure I need to build for this, any help would be much appreciated.

      infinitymdm I have read somewhere that electron apps are generally frowned upon in Solus.

      As a general rule people do not like electron apps. Solus has no position on them.

      I tend to see electron / yarn and run as they can be a pain to package. But many people including me use vscode and etcher.

      This will not be beginner friendly but this should get you some progress.

      yarn
      yarn dist tar.xz

      You will have to manually copy/install everything built from a specific directory to the $installdir for packaging. Putting things in the correct location and creating symlinks etc. Potentially having to create a heroic.desktop file to ship with it as I do not think it is generated using the above method.

      These packages will contain some examples of things you'll need to do when it comes to manually installing but there can be no universal guide:

      https://dev.getsol.us/source/vscode/browse/master/package.yml
      https://dev.getsol.us/source/vivaldi-stable/browse/master/package.yml (Not electron but has a manual aspect to it).

      Assuming you are building it against the unstable repository. Once you have managed to build it but not successfully create a .eopkg you'll be able to run sudo solbuild chroot -p unstable-x86_64 which will allow you to browse the directory structure and see what is there and where to put it (exit to exit the chroot environment).

        Okay so, I got bored...

        I'll be honest I have little experience with electron / yarn so there may be a better way. But this is as far as I can get without actually putting real thought into it and this is as far down the rabbit hole as I am going.

        You still need:

        • heroic.desktop installed to $installdir/usr/share/applications/ so it appears in your system menu.
        • Icons installed to their respective $installdir/usr/share/icons/hicolor/{size}/apps/heroic.png
        • legendary? (CLI utility mentioned in description) symlink for $installdir/usr/bin/
        • Sort out any run dependencies.

        But I think initial work is done, I have not tested it as I have 0 interest in Epic.

        I added every build dependency it complained about not finding during post build but there almost certainly are redundancies (dependencies of dependencies do not need to be added) and run deps have not been done at all.

        Best of luck.

        name       : heroic-games-launcher
version    : 2.1.1
release    : 1
source     :
    - git|https://github.com/Heroic-Games-Launcher/HeroicGamesLauncher.git : v2.1.1
license    : GPL-3.0-or-later
component  : games
networking : yes
summary    : A native GUI Epic Games Launcher for Linux.
description: |
    Heroic is an Open Source Game Launcher for Linux for both Native and Windows Games using Crossover. It also supports launching games from the Epic Games Store using Legendary, a CLI alternative.
builddeps  :
    - pkgconfig(alsa)
    - pkgconfig(atk)
    - pkgconfig(atk-bridge-2.0)
    - pkgconfig(atspi-2)
    - pkgconfig(cairo)
    - pkgconfig(gbm)
    - pkgconfig(gdk-pixbuf-2.0)
    - pkgconfig(gtk+-3.0)
    - pkgconfig(libdrm)
    - pkgconfig(pango)
    - pkgconfig(xcomposite)
    - pkgconfig(xdamage)
    - pkgconfig(xfixes)
    - pkgconfig(xkbcommon)
    - pkgconfig(xrandr)
    - pkgconfig(xshmfence)
    - cups-devel
    - git
    - yarn
setup      : |
    yarn
build      : |
    yarn dist tar.xz
install    : |
    install -dm00755 $installdir/usr/share/Heroic
    install -dm00755 $installdir/usr/bin
    cp -R ./dist/linux-unpacked/* $installdir/usr/share/Heroic/
    ln -s /usr/share/Heroic/heroic $installdir/usr/bin/heroic

          Harvey thanks for your help. I've made quite a few updates. The last hurdle is the desktop file.

          How is this usually done? I can echo it out to a file in the install section, but that seems incredibly inelegant. I can't just create a static file, because it needs to have the $installdir swapped in for the Exec and Icon fields. Any pointers for me?

              infinitymdm
              Most of the time no special actions need to be taken but this is not one of those times.

              You need to create the directory files inside the directory for this package. Inside the files directory create a text file called heroic.desktop which containing the following:

              [Desktop Entry]
Name=Heroic Games Launcher
Exec=/usr/bin/heroic %U
Terminal=false
Type=Application
Icon=heroic
StartupWMClass=Heroic
Comment=An Open Source alternative to the Epic Games launcher
MimeType=x-scheme-handler/heroic;
Categories=Game;

              In the install section of the package.yml add this line:
              install -Dm00644 $pkgfiles/heroic.desktop $installdir/usr/share/applications/heroic.desktop

              vscode does the same thing.

                  That did the trick. Everything appears to be working now. After installing and rebooting, the app shows up in the menu correctly. The next step will be writing up a comprehensive readme so that other folks can easily build and install.

                  Harvey I'm incredibly grateful for your help. I think you did the majority of the work for this (thanks again 😅 ), but it's definitely been a learning experience for me. If you don't mind, I'd like to ask a few more questions, to make sure I understand things correctly:

                  1. Why is the .desktop file funny in this case? I assume in most cases this file is automatically generated from the package.yml and the installed binaries. Is this one abnormal because we have both the heroic and the legendary binaries symlinked to /usr/bin?
                  2. In my stumbling about I came across T9656 on the Solus task tracker. Now that things are working, is this something I should consider submitting there?
                  3. Why is it OK for some packages to use networking : yes when this is heavily discouraged? If I were to submit this for inclusion, would that be something I would need to change?

                      infinitymdm

                      You are welcome.

                      1. Why is the .desktop file funny in this case?

                      I will be honest perhaps it is my ignorance of electron / yarn or maybe it is just how this one is setup. Electron / yarn always seems hacky to me and this experience has not changed my opinion. To be fair there are cases where non-electron apps do not provide a .desktop file either but...

                      HGL seems to support .deb, .rpm, .pacman, appimage and a generic .tar.xz package. They do not provide any instructions on generic Linux build just those packages. Reality is we do not want them to package it. Even if they supported Solus we would not use their package, we would want to use our own tooling to create the package. It seems aimed towards users not maintainers and their practices. I looked just now to see what other distros are doing, very few have the package an those that do are using the packages provided and / or repackaging them.

                      The tar.xz option does not seem to generate a .desktop file and for .pacman they are installing to /opt which we do not allow for packages included in the repository so the generated .desktop file would need modification. The tar.xz option however did contain an unpackaged directory which made the manual process easier.

                      The language the program is in has an impact on the build systems viable to a project. Some have an easily customisable configuration and install section, some do not. Then there are accepted standards of that build system and its implementation in that project as well as your experience as a maintainer in dealing with it.

                      In contrast, protontricks is very easy to package:
                      https://dev.getsol.us/source/protontricks/browse/master/package.yml

                      You can see the files the .eopkg will contain, including the .desktop file here : https://dev.getsol.us/source/protontricks/browse/master/pspec_x86_64.xml$58

                      That is not a python specific thing or because it is a very simple application. I will take everything over electron.
                      https://dev.getsol.us/source/kid3/browse/master/package.yml

                      So do not be discouraged if you found this puzzling, electron is... electron.

                      1. In my stumbling about I came across T9656 on the Solus task tracker. Now that things are working, is this something I should consider submitting there?

                      If you wish to become the package maintainer for this application you can do so. If something is accepted for inclusion and marked as needing a maintainer, you do not need to request permission, you just need to do the work, submit it and be willing to take on the responsibility to keep it reasonably up to date etc. Details are explained here https://getsol.us/articles/packaging/

                      Once submitted via the proper method, it will wait for team review. They will ask you to make certain changes for example the line "networking : yes" should be right after the component line, make sure there are no redundant dependencies etc, etc. Once they are happy they will accept it and it will land in the unstable repository for testing and from there the stable repository next sync.

                      1. Why is it OK for some packages to use networking : yes when this is heavily discouraged? If I were to submit this for inclusion, would that be something I would need to change?

                      It is a good practice when it comes to permissions, do not give more than is needed. Most packages do not require it and when something does, you are making a conscious effort to allow it.

                      Yarn requires it, so its okay, you will not need to disable it in order to submit it for inclusion. vscode needs it for the same reason. micro needs it for git submodules as do several other packages.