Porting X11Libre to FreeBSD.

baaz said:
As per T-Aoki's suggestions to move the FLAVORs discussions to the forms, I will be posting this here.

I have tried few times to describe this situation solely with text but I figured out a little visual aid would help make things much clearer and easier to communicate.

So here are few slides and diagrams that I made on regarding this topic:


(The forum file size limit was not sufficient so I had to resort to GitHub pages)
Click to expand...
At least "Updates" part is inaccurate.
One of the person in current de-facto maintaining team accepted changes to x11/nvidia-driver, but I (mainly maintaining it and related driver ports) and former maintainer (danfe@) are objecting.

Commit was done while I was writing objectiong comment (caused mid-air collision when I attempt to save my comment) after I've finished my daytime $work and noticed PR 291598. Further discussions are going to be made on PR 291594 as per comment 8.
 
T-Aoki
(from PR 291594)
I don't object for FLAVORization if both Xorg implementation and XLibre implementation of X11 server can sanely coexist in single installation, selectable, i.e., via libmap or alike on startup. But currently XLibre conflicts with Xorg implementation.
Click to expand...
Could a coexistence be possible?
 
HayPhil said:
T-Aoki
(from PR 291594)

Could a coexistence be possible?
Click to expand...
I think "technically" possible.
Rename conflicting files to something different (i.e., /usr/local/bin/X for XLibre to /usr/local/bin/X.XLibre, for Xorg to /usr/local/bin/X.Xorg and create wrapper port to choose proper one and symlink from /usr/local/bin/X).
Limited with libraries, libmap would work. But others would need something like above. Anyway, large rework. So I said "technically". Maybe objections would arise, like current FLAVORized implementation.
 
HayPhil said:
T-Aoki
(from PR 291594)

Could a coexistence be possible?
Click to expand...

No, XLibre uses the same binary name, wrapper name, .pc file and ... .

This is to keep backwards compatibility with many tools, scripts and ..., that depend on these being named as such, and changing it would break a huge number of use cases.

I do not understand why this has anything to do with FLAVORS.
 
baaz said:
I do not understand why this has anything to do with FLAVORS.
Click to expand...
Because I don't think FLAVOR is good thing for conflicting things.
Default alone should be packaged and non-default conflicting things would be better built locally as per admin's choice.
This was what happened on transition from XFree86 to Xorg. Conflicting each other (except for things carried over from Xfree86, named xf86-*).

As there were no USES nor DEFAULT_VERSIONS implemented at the moment, so make variable WITH_NEW_XORG was introduced (now obsolete and deleted as the transition finished). Packages were built for XFree86 only and anyone want to try Xorg before official transition happened built Xorg locally. Why not for this time? Now we have DEFAULT_VERSIONS and USES framework.
 
T-Aoki said:
Packages were built for XFree86 only and anyone want to try Xorg before official transition happened built Xorg locally. Why not for this time? Now we have DEFAULT_VERSIONS and USES framework.
Click to expand...
XFree86 and Xorg were both monolithic back then; so things were a little easier for people to handle locally admittedly.
Because Xorg and Xlibre are split up into random fragments and not all of them are forked, I can assume it needs to be handled a little differently.
 
T-Aoki said:
I think "technically" possible.
Rename conflicting files to something different (i.e., /usr/local/bin/X for XLibre to /usr/local/bin/X.XLibre, for Xorg to /usr/local/bin/X.Xorg and create wrapper port to choose proper one and symlink from /usr/local/bin/X).
Limited with libraries, libmap would work. But others would need something like above. Anyway, large rework. So I said "technically". Maybe objections would arise, like current FLAVORized implementation.
Click to expand...
So then anything you want to run under Xlibre has to be aware of these mangled names? How's that simpler than FLAVORS?
 
Jose said:
So then anything you want to run under Xlibre has to be aware of these mangled names? How's that simpler than FLAVORS?
Click to expand...
Have you read the whole post?
I've written "and create wrapper port to choose proper one", means, everything currently provided by both needs kinda wrapper keeping each filenames should be created by the wrapper port as symlink to whichever chozen (via OPTIONS preferrably, but in this case, FLAVOR is acceptable).
But this causes massive renames of existing Xorg ones.
 
T-Aoki said:
Have you read the whole post?
I've written "and create wrapper port to choose proper one", means, everything currently provided by both needs kinda wrapper keeping each filenames should be created by the wrapper port as symlink to whichever chozen (via OPTIONS preferrably, but in this case, FLAVOR is acceptable).
But this causes massive renames of existing Xorg ones.
Click to expand...
Yeah, my bad. Still a whole lot more work than the simple flavorized approach baaz implemented, and still way more friction to someone that just wants to try out Xlibre without spending a bunch of time on it.
 
Last edited:
OK, some more technical stuff.
I have found a better, more elegant solution to the KDE problem.

The entire reason that the KDE x11/plasma6-plasma-desktop port can't be installed alongside xlibre-server is due to its RUNTIME dependency on X.Org drivers:

x11-drivers/xf86-input-libinput

and

x11-drivers/xf86-input-evdev


Now why is there a dependency on these two drivers in the first place?

It is because of the diabolical scheme that was put into place for communicating default values of properties associated with xf86-input-* drivers to the input configuration utilities present in desktop environments.

Instead of a simple, humble text file, the xf86 input drivers generate a C header and a pkgconf file that is then depended on and included by a DE's input configuration tool, and it in turn sets its default values based on the list of "#define"s in these header files.


The things to note:

  • This is done for just setting the default values of these configuration utilities.
  • All of this is happening during compile time.

The libinput driver is basically the only ** driver whose exported properties are depended on by other ports. Moreover, those properties are based on the defaults of libinput itself.

So, by letting these ports just depend on xf86-input-libinput during build time instead of xlibre-xf86-input-libinput, we are not breaking anything for XLibre users because the exported properties by these drivers are based on the shared libinput library's defaults and are the same between XLibre and X.Org. (Even if we were to break anything, it would just make the default values of the GUI configuration utilities for XLibre users have different values).


The problem that we are currently facing is that the KDE Plasma 6 Desktop port not only depends on these ports in build time but also in run time, and I have found this runtime dependency to be unnecessary. I have not found anything in x11/plasma6-plasma-desktop that requires a hard dependency on these drives in runtime. I have even searched some of the Linux package repos, and they all listed these 2 drivers as build-time dependencies of plasma-desktop:

https://github.com/void-linux/void-packages/blob/master/srcpkgs/plasma-desktop/template

https://archlinux.org/packages/extra/x86_64/plasma-desktop/

By just removing the runtime dependency of x11/plasma6-plasma-desktop on these two drivers and keeping their build-time dependencies, we can solve this issue without needing to use any FLAVORs.

So just a ~2 line diff:


Diff: 
diff --git a/x11/plasma6-plasma-desktop/Makefile b/x11/plasma6-plasma-desktop/Makefile
--- a/x11/plasma6-plasma-desktop/Makefile
+++ b/x11/plasma6-plasma-desktop/Makefile
@@ -19,9 +19,7 @@
 LIB_DEPENDS=  libcanberra.so:audio/libcanberra \
                 libxkbcommon.so:x11/libxkbcommon \
                 libxkbfile.so:x11/libxkbfile \

 RUN_DEPENDS=   noto-emoji>0:x11-fonts/noto-emoji \
-               xdg-user-dir:devel/xdg-user-dirs \
-               xf86-input-evdev>0:x11-drivers/xf86-input-evdev \
-               xf86-input-libinput>0:x11-drivers/xf86-input-libinput
+               xdg-user-dir:devel/xdg-user-dirs
 USES=          cmake gettext gl gnome kde:6 pkgconfig python qt:6 tar:xz xorg
 USE_GL=                gl opengl




** The evdev input driver is also depended by plasma-desktop but it has been removed:
github.com

kcms/mouse: Remove unused xorg-evdev dependency · KDE/plasma-desktop@b4fe3e9

It's not necessary to access it directly anymore, now that we only expose settings for libinput.
github.com github.com
 
You must log in or register to reply here.
Back
Top