Porting X11Libre to FreeBSD.

kpedersen · Monday at 4:59 PM

Very useful (and reasonable) slides. Thanks for preparing that.

T-Aoki · Monday at 5:23 PM

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:

https://b-aaz.github.io/flavors-vs-default_version.pdf

(The forum file size limit was not sufficient so I had to resort to GitHub pages)

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.

Jose · Monday at 11:23 PM

I have only a rudimentary understanding of how the ports framework operates, but FWIW I'm convinced the FLAVORS version is the way to go right now.

HayPhil · Tuesday at 1:54 PM

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.

Could a coexistence be possible?

T-Aoki · Tuesday at 2:34 PM

HayPhil said:
T-Aoki
(from PR 291594)

Could a coexistence be possible?

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.

baaz · Tuesday at 2:34 PM

HayPhil said:
T-Aoki
(from PR 291594)

Could a coexistence be possible?

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.

T-Aoki · Tuesday at 2:44 PM

baaz said:
I do not understand why this has anything to do with FLAVORS.

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.

kpedersen · Tuesday at 3:49 PM

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.

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.

Jose · 2025-12-17T01:45:36+0000

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.

So then anything you want to run under Xlibre has to be aware of these mangled names? How's that simpler than FLAVORS?

T-Aoki · 2025-12-17T09:11:28+0000

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?

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.

Jose · 2025-12-17T16:04:21+0000

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.

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 ie.