xpra is a xorg-capable variant of 'screen'.
Fixes T9894
JoshStrobl |
Triage Team |
xpra is a xorg-capable variant of 'screen'.
Fixes T9894
With xorg-server-xvfb testing succeeds.
No Linters Available |
No Unit Test Coverage |
Buildable 2391 | |
Build 2391: arc lint + arc unit |
package.yml | ||
---|---|---|
8 | Needs to be checked | |
14 | docs get automatically patterned out when necessary. | |
17 | Check reverse dependencies of various deps to know what pkgconfigs you can remove. | |
29 | Most of these aren't necessary. Check what the package is already linking to, check eopkg info on the generated eopkg, and remove many of those deps that are already going to be installed, part of the base image, or reverse dependencies. |
You can clean more deps, because they are dependency of pkgconfig(gdk-3.0)
- pkgconfig(xrandr) - pkgconfig(xdamage) - pkgconfig(xcomposite)
Also you have to move cython and pandoc after pkgconfig(xtst).
Not sure if libgtk-3 and libxtst should be explicitly added to rundeps, becuase there are libXtst.so.6 and libgdk-3.so.0 present in abi_used_libs that automatically links to these rundeps.
Unfortunately the setup.py handles the install dir in a weird way, so some paths are not configured right now.
But it works now.
Bunch of patching needing to be done to this to put it in the correct sysconfdir.
package.yml | ||
---|---|---|
14 | Prefer to use gtk+-3.0 as the pkgconfig | |
17 | Not needed. Dep of libgtk-3-devel. | |
18 | Not needed. Dep of libgtk-3-devel. | |
20 | Again another dep of libgtk-3-devel.. | |
21 | Dep of at-spi2-devel, which is a dep of at-spi2-atk-devel, which is a dep of libgtk-3-devel. | |
pspec_x86_64.xml | ||
24 | Not valid. Should be /usr/share/X11/xorg.conf.d/ | |
25 | Should be /usr/share/dbus-1/system.d | |
26 | Needs to be patched to be /usr/share/defaults/xpra | |
52 | /usr/lib64/[...] | |
53 | /usr/lib64/[...] |
Dep of at-spi2-devel, which is a dep of at-spi2-atk-devel, which is a dep of libgtk-3-devel.
@JoshStrobl Uff, do you dig into all reverse dependencies through all levels or do you now this from your experience?
The first one were obvious and I have overlooked them.
Thank you @JoshStrobl, I will have a deeper look into the make process of xpra to fix the paths.
I'd say this is a good first start, much more of an improvement over the initial patch, so I'm going to be accepting it as-is. Thanks for the work you have put into this.
If you are interested in improving it even further in a subsequent patch to have it reach even higher standards and provide a learning opportunity for yourself, here are the things you can do:
None of this is really your fault. Just a bunch of improvements that upstream could support (for example, stateless support would enable users to apply their own configuration files on a system-wide scope while still falling back to any defaults ourselves or upstream decides in a /usr/share/defaults/xpra stateless folder).