Packaging Valve's Proton

[Alexandre Viau]

Hello all!


I have just sent a request to join the games-team on salsa :)

I'd like to ask if this would be the right team to work on packaging
Valve's Proton?

Has anyone looked into it yet? Do we know if it would be maintainable in
main?

I'd love to help wherever I can. Is there somebody interested in working
on this with me?

Cheers,

[Paul Wise]

Post by Alexandre Viau
I'd like to ask if this would be the right team to work on packaging
Valve's Proton?

Proton seems to involve a fork of Wine, so I think it would be best to
involve the Debian team for that.

Post by Alexandre Viau
Has anyone looked into it yet? Do we know if it would be maintainable in
main?

I'm not sure it is a good idea

Post by Alexandre Viau
I'd love to help wherever I can. Is there somebody interested in working
on this with me?
Cheers,
--
Alexandre Viau

[Paul Wise]

[woops, sent before completing the mail]

Post by Paul Wise

Post by Alexandre Viau
Has anyone looked into it yet? Do we know if it would be maintainable in
main?

I'm not sure it is a good idea

... to package something that requires a fork of Wine.

It also seems to build-depend on a docker container, that would need
to be replaced with proper build dependencies.

[Alexandre Viau]

CC-ing debian-wine@

Hello debian-wine!

I have just sent a mail to debian-games@ about the possibility of
packaging Proton[1] for Debian. I wanted to know if you were interested
in getting involved, of if you had already spent some time evaluating it?

I am also interested in getting DXVK in Debian. That would be the first
step since Proton depends on it.

If we can't get Proton in Debian, DXVK + Wine is also a great step
forward for folks that play video games on Debian.

Lutris already ships some scripts that use Wine and DXVK (without
Proton) to play games and they are getting great results.

Post by Paul Wise
[woops, sent before completing the mail]

Post by Paul Wise

Post by Alexandre Viau
Has anyone looked into it yet? Do we know if it would be maintainable in
main?

I'm not sure it is a good idea

... to package something that requires a fork of Wine.

I wouldn't be surprised if we got Proton to work without the wine fork,
compromising on some of the features.

Post by Paul Wise
It also seems to build-depend on a docker container, that would need
to be replaced with proper build dependencies.

It dosen't really need that docker container. They involve Docker in
their build system to ensure that the builds are done the right versions
of the right libraries, and they also include proprietary steam runtime
libraries that are not needed for a vanilla Proton build.

Post by Paul Wise
You can skip the Docker and Steam Runtime setup steps below, as they
take a very long time to set up. At configure-time, pass the --no-
steam-runtime flag instead of the Docker flags shown here.

[1] https://github.com/ValveSoftware/Proton
[2] https://github.com/ValveSoftware/dxvk

Cheers,

[Simon McVittie]

Post by Alexandre Viau

[Proton] also seems to build-depend on a docker container, that would need
to be replaced with proper build dependencies.

It dosen't really need that docker container. They involve Docker in
their build system to ensure that the builds are done the right versions
of the right libraries, and they also include proprietary steam runtime
libraries that are not needed for a vanilla Proton build.

They might *also* be including proprietary Steam libraries, but in
general the term "Steam Runtime" refers to Steam Runtime v1 'scout', a
small Ubuntu derivative (based on Ubuntu 12.04 'precise') containing all
the open-source libraries you'd expect, used to give the Steam client and
Steam games a predictable baseline for library dependencies. Originally,
the script that launches the Steam client would preferentially use the
Steam Runtime libraries via LD_LIBRARY_PATH for everything, only using
host system libraries for things not in the Steam Runtime (notably
glibc and 3D drivers). It now uses either the host system or the Steam
Runtime (whichever appears newer) for each individual library, with a
few exceptions.

The Docker container used to build official Proton binaries is probably
only there to make sure its dependencies are limited to the Steam Runtime.
For binaries that target Debian, we don't need to impose that constraint;
it can be free to target host system libraries, with dpkg-shlibdeps
ensuring that it has the right dependencies to support them.

smcv

[Alexandre Viau]

Post by Simon McVittie
They might *also* be including proprietary Steam libraries, but in
general the term "Steam Runtime" refers to Steam Runtime v1 'scout', a
small Ubuntu derivative (based on Ubuntu 12.04 'precise') containing all
the open-source libraries you'd expect, used to give the Steam client and
Steam games a predictable baseline for library dependencies. Originally,
the script that launches the Steam client would preferentially use the
Steam Runtime libraries via LD_LIBRARY_PATH for everything, only using
host system libraries for things not in the Steam Runtime (notably
glibc and 3D drivers). It now uses either the host system or the Steam
Runtime (whichever appears newer) for each individual library, with a
few exceptions.

Ah, thanks for the explanation!

I have started working on packaging dxvk. I have a working package but I
still use the embedded libraries in upsteam's source tarball.

I have sent a mail to debian-x and debian-wine about it, maybe I should
have included debian-game, so I am linking it here:
- https://lists.debian.org/debian-x/2018/10/msg00098.html

Cheers,