Redesign Platform & Sdk Structure (again)

[julianrichen]

tldr; wine-staging as extensions is bad, and I kind of knew it -_-. Move wine-staging to runtime and make runtime better overall.

This issue extends off the discussion from winepak/applications#16

Background

Originally when I was designing winepak I had every wine version as a different runtime, eg:

• org.winepak.Platform//3.0
• org.winepak.Platform//3.9-staging
• org.winepak.Platform//3.10-staging

However, I changed that with #2. After considering it more, this was a bad choice and doesn't do things the "flatpak way". Or at least its a gross abuse of extensions.

Why was it changed in the first place?

I split the wine version into extensions due to two concerns:

• Disk Space
• Bandwidth

For example, I didn't want users download 6 massive runtimes (~ 1.1GB for x86_64, and 1GB for i386) for 6 applications. Instead having users only download a 200MB extensions was better. This would also lower bandwidth usage since less data was needed.

flatpak tries to de-duplicate as much as possible and disk space is cheap. I can scale-up server if need be (with reason). Considering the problems below, the "solution" out-ways the cons.

Problems

1

Users can uninstall extensions which can throw nasty errors as an app can't find the needed wine version. flatpak treats extensions as optional and wont warn users if they uninstall an extensions that an app is using. Such errors are along the line of "This prefix is using a different version of Wine" or "No wine found in path". Not a good user experience.

This isn't true for runtimes and will warn users.

2

It clutters the $PATH variable. This is less forward facing to users but on the technical side this make me want to vomit:

- --env=PATH=/app/bin:/app/lib/wine/bin:/app/lib/wine-32bit/bin:/app/lib/32bit/wine:/usr/lib/wine/bin:/usr/lib/wine-32bit/bin:/usr/bin:/usr/lib/32bit/bin

It checks a lot of places for wine and if a manifest where to override the $PATH variable without thinking, things would break... it also feels dirty.

3

Multiple wine binaries, causing possible issues. This is somewhat tied to problem 1 in the event of a user uninstalling a wine-staging version, and the app can't find it. It defaults to the stable 3.0 wine. Which throws nasty errors saying the prefix is different. This can theoretically happen because of some random reason if for any reason the wine-staging extension doesn't get mounted.

4

You can't test multiple wine versions since you can't change extensions at runtime. However, you can change runtimes with the --runtime= argument:

flatpak run --runtime=org.winepak.Platform//3.xx-staging tld.domain.Application

This should actually be a strength of flaptak-ing wine and I basically removed the features. Being able to quickly swap wine versions with a stable Platform/Sdk would be amazing for testing and help upstream wine with reports. I want this feature back.

5

The flatpak devs pointed out this isn't the way extensions where intended to be used. It's not the "flatpak way". It's also bad practices to use a hacky approach to make something work. Lets do it right.

Solution

I've been trying to think of the best way to solve this. Before the obvious "just make it a runtime?!?" comment I have other concerns. Another gain from making wine into an extension was the compile time. The Sdk & Platform take a bit more time to build with their post-script stuff. Plus we need to build other packages. Currently that's openldap, bdb, cabextract + non-compiled wine-mono, wine-gecko. I would also like to add unrar since that can be handy. I would also like to get most of the wine compile flags ticked to enabled instead of disabling a lot.

Another issue is what about wine-mono and wine-gecko? If they need to be updated then we have to re-compiling the whole Sdk & Platform for say Wine 3.0 and all staging versions (3.8 ~ 3.xx). That's silly and a waste of time.

So what's the solution?

1 - Base Platform & Sdk

First we borrow from the freedesktop Platform & Sdk. First we create a base winepak Platform & Sdk, with the ids:

• org.winepak.BasePlatform
• org.winepak.BaseSdk

This has all the compiled packages we want that aren't wine, so currently that would be:

• openldap
• bdb
• cabextract
• unrar
• more in the future

We then base the org.winepak.Platform and org.winepak.Sdk off the base Platform & Sdk. This will help reduce new compiles and recompile times since we are building off a common base for the 3.x version of wine. No need to rebuild the above packages, wooh!

2 - Make wine-mono and wine-gecko extensions

Wine mono & gecko are fairly independent and update irregularly. This is actually a good candidate for extensions. So we make org.winepak.Platform.Gecko and org.winepak.Platform.Mono:

org.winepak.Platform.Gecko:
  directory: lib/gecko
  version: 3.0
  versions: 3.0
  subdirectories: false
  autodelete: false

org.winepak.Platform.Mono:
  directory: lib/mono
  version: 3.0
  versions: 3.0
  subdirectories: false
  autodelete: false

Then we symlink:

• /usr/share/wine/gecko -> /usr/lib/gecko
• /usr/share/wine/mono -> /usr/lib/mono

with versioning for extensions being:

• org.winepak.Platform.Gecko.2-40//3.0
• org.winepak.Platform.Gecko.2-44//3.0
• org.winepak.Platform.Gecko.2-47//3.0
• org.winepak.Platform.Mono.4-7-0//3.0
• org.winepak.Platform.Mono.4-7-1//3.0
• org.winepak.Platform.Mono.4-7-2//3.0

This would act similar to how the org.freedesktop.Platform.GL extension point is for Nvidia, eg. org.freedesktop.Platform.GL.nvidia-390-67//1.4

I believe we can have numeric only segment in the app-id, otherwise we can do org.winepak.Platform.Gecko.gecko-2-40//3.0.

3 - Building wine x.x.x version

We then can quickly and easily build x.x.x versions of wine. Example manifest:

build-runtime: true

id: org.winepak.Sdk
id-platform: org.winepak.Platform
branch: 3.0

runtime: org.winepak.BasePlatform
runtime-version: 3.0
sdk: org.winepak.BaseSdk

...

modules:
    ... just the wine stuff ...

Finial notes

I think this the right direction and should make winepak more robust and future proof. I wrote all this up to document my thoughts and for other users to comment if they see an issue.

I'll be trying to work on it, however, in a few days I leave for 2.5 weeks to see family where I won't have wifi or a powerful machine to compile on. Just a Google Chrombook Pixel with Fedora 28 flash on it :/ So this will probably take a while before it's done.

[julianrichen]

I think most of the important stuff is done today but want to do more testing and checking tomorrow and the day after.

One issue I'll have with this is having to-do a mass rebuilt, which isn't bad since the repo is still small. Since winepak's version-ing is based on Wine version (3.0, 3.11-staging, 3.12-staging, etc..) and not our own version (eg. fd.o//1.4 -> fd.o//1.6 -> etc) old apps will break if I just push the Sdk & Platform. This isn't really avoidable because this is a change to fix a bad design decision. Luckily the project is still small :)

I will need to merge Sdk, Platform, and change all the applications to use the new runtime format. Then I can rebuild locally and push all at once.

Unless some app does't work most will be rebased on 3.11-staging or 3.12-staging. Ideally I want to build 3.1-staging to 3.10-staging so we can test the whole 3.x series but that work is for a later date.

[julianrichen]

TODO: Add following lines to ld.so.conf since we include the *.Compat.i386 extension in the runtime now. Need to add search paths for i386 & GL32 libs.

include /run/flatpak/ld.so.conf.d/app-*-org.freedesktop.Platform.GL32.*.conf
/usr/lib/i386-linux-gnu/lib

Probably something along the lines of this in cleanup-commands & cleanup-platform-commands. Or in the last module.

echo "include /run/flatpak/ld.so.conf.d/app-*-org.freedesktop.Platform.GL32.*.conf" >> ld.so.conf
echo "/usr/lib/i386-linux-gnu/lib" >> ld.so.conf

[julianrichen]

The above is done.

[julianrichen]

Investigate: Can we include Compat.i386 builds directly in the x86_64 build now that flaptak-builder >= 0.99.1 "Allow[s] building SDK extensions that require SDK extensions"?

I would still want to keep the *.Compat.i386 extension point at lib/i386-linux-gnu but if we can include the wine files during build to say lib/32bit or similar that would hopefully remove the problem of users deleting org.winepak.Platform.Compat.i386 from their system.

Source: flatpak/flatpak-builder#156

[julianrichen]

fd.o 18.08 (previously known as 1.8) is officially released and should be on flathub soon is on flathub:
https://lists.freedesktop.org/archives/flatpak/2018-August/001233.html

I was hoping this would happen soon so the design change of the SDK would use the latest and greatest fd.o.

[julianrichen]

fd.o//18.08 already symlinks /usr/lib/i386-linux-gnu to /app/lib/i386-linux-gnu:

$ flatpak run --command=sh org.freedesktop.Sdk//18.08
sh-4.4$ ls -la /usr/lib/i386-linux-gnu
lrwxrwxrwx 1 nfsnobody nfsnobody 28 Aug 17 10:02 /usr/lib/i386-linux-gnu -> ../../app/lib/i386-linux-gnu

which is causing build errors:

========================================================================
Building module platform-setup in /home/julian/Projects/winepak/.flatpak-builder/build/platform-setup-1
========================================================================
Running: mkdir -p /usr/share/runtime/docs
Running: mkdir -p /usr/lib/sdk
Running: mkdir -p /usr/lib/extension
Running: mkdir -p /usr/lib/gecko
Running: mkdir -p /usr/lib/mono
Running: mkdir -p /usr/lib/i386-linux-gnu
mkdir: cannot create directory ‘/usr/lib/i386-linux-gnu’: File exists
Error: module platform-setup: Child process exited with code 1

While the mount point could be changed to say /usr/lib/i386-linux-gnu-wine overriding the standard mount point for fd.o//18.08 might be stupid. It may be beneficial to not override fd.o//18.08 settings and have each app declare the need for Compat32/Compat.i386/WoW64 support. While this does add more lines to each manifest the ability to retain control over Compat in each app would be smart. Plus it would also allow apps that really only need 64bit support to drop the org.winepak.(Sdk|Platform)/i386 package.

[julianrichen]

Investigate: BDB is failing on 18.08 causing build errors.

make: *** [Makefile:2443: cxx_txn.lo] Error 1
libtool: compile:  g++ -c -I. -I./src -O2 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT -O2 -g -fstack-protector-strong -O2 -g -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I./lang/cxx/stl lang/cxx/stl/dbstl_container.cpp -o dbstl_container.o >/dev/null 2>&1
Error: module BDB: Child process exited with code 2

org.winepak.Sdk_based_on_fd.o_18.08_fails.txt

[gasinvein]

Probably you should build both .BaseSdk and .Sdk against same org.freedesktop.Sdk version 18.08:
https://github.com/winepak/winepak-sdk-images/blob/331a9f98524329237f06a30b6a304940c912fce4/org.winepak.BaseSdk.yml#L3-L8
https://github.com/winepak/winepak-sdk-images/blob/331a9f98524329237f06a30b6a304940c912fce4/org.winepak.Sdk-315-staging.yml#L3-L8
Mixing different ABIs versions is bad idea.

[julianrichen]

@gasinvein Oops, I don't actually use BaseSdk. I did a rebase from master to pull in the vcrun2017 extension & fixes that I was missing in the redesign branch but messed some things-ups. Ended-up pulling files not used any more. Will fix, thanks for catching that.

[gasinvein]

Why did you remove BaseSdk? It seems good idea and totaly flatpak way. Also, it would keep versioned Sdk mainfests much simplier.

[refi64]

Related question: is there a reason winepak's runtime isn't an extension? E.g. for applications that require Wine but don't necessarily only use Wine and need deps on another runtime.

[gasinvein]

@kirbyfan64 I guess in that case wine should be bundled with the application.

[kklem0]

Hi @julianrichen ,

Is this exciting project still alive? :)