Would it be worth it for a xorg-basic metaport?

Should I make a xorg-basic metaport if I ever have the time?

  • Yes, that would be useful!

    Votes: 5 41.7%

  • No, I want to keep my choice of two already bloated meta ports.

    Votes: 4 33.3%

  • "I use Wayland"

    Votes: 3 25.0%
  • Total voters
    12
RetroComputingCollector

RetroComputingCollector

After what I said in Xorg meta port extremely bloated with linux crap, I have considered making a xorg-basic meta port that is only x11-servers/xorg-server, x11/x11-apps, x11/xorg-libraries, x11/xbitmaps, x11-fonts/xorg-fonts, x11/xdm, and x11-drivers/xf86-video-vesa. I don't have much time on my hands (and I will not for the foreseeable future) to maintain a port, but if some time frees up, I would, if the community would be interested in this. Because I can't do this right now (so don't expect me to), I hope someone else with more time decides to do something like this. I also need to find some way of getting rid of mesa-dri, as that brings in so much junk, so maybe there would have to be a xorg-basic server that just removes the dependency on that Linux crap
.
 
I'm not voting, but we already have xorg, xorg-minimal. My opinion is what you propose should be xorg-minimal and an xorg-basic would be in between the two.
 
I had to vote no, though I use neither. I just run
Code: 
pkg install xorg-server alacritty feh dmenu openbox xf86-input-libinput xinit xauth
And some Nvidia drivers on one workstation that has it. Though the packages I mentioned above will pull in a lot of stuff. But on a vm in bhyve,
those plus xf86-video-scfb will get me a working window manager. And, whatever video driver I might need for bare metal, depending on the machine.
 
scottro said:
I had to vote no, though I use neither. I just run
Code: 
pkg install xorg-server alacritty feh dmenu openbox xf86-input-libinput xinit xauth
And some Nvidia drivers on one workstation that has it. Though the packages I mentioned above will pull in a lot of stuff. But on a vm in bhyve,
those plus xf86-video-scfb will get me a working window manager. And, whatever video driver I might need for bare metal, depending on the machine.
Click to expand...
This would make it easier for new users to get the proper X11 experience. I based this off of my own package list!
 
Do you mean the metaport? If you mean mine, when installing on actual hardware, I usually also pull in kmods, edit rc.conf and a few other tweaks, but the list I gave above work on VMs at least.
 
Is it really worth the effort? Just for the sake of avoiding "Linux crap"? To me it looks just ideological nonsense.
 
I've not looked through the xorg dependency tree recently. (Its too gross).

It sounds to me that xorg-minimal should be *fixed* and that mesa-dri should be *fixed*. It may be the harder route but collaborating with the existing maintainer of those ports will likely be the better approach here.

Or, (again more work) focus on Xlibre and see if a monolithic port can be created, collaborating with Baaz's work, bringing us more inline with the other BSDs.

... Or, if you feel up for some C++ and only need to display stuff, skipping the whole of Xorg and Wayland, I could do with some help reinstating vgl(3) ontop of libdrm (basically a port from OpenBSD -> FreeBSD).
 
Maxnix said:
Xorg doesn't require neither glib nor Python to run, but I suspect that glib could be dragged in by a dependency of x11-drivers/xf86-input-libinput.
Click to expand...
Also, mesa-dri brings in loads of junk. I think someone should message the maintainers of all of these ports and ask them if debloating them of their dependencies would be possible. I think all of this Linux dependency garbage should be made optional if possible.
 
RetroComputingCollector said:
Also, mesa-dri brings in loads of junk.
Click to expand...
What junk? These are the dependencies of a stock mesa-dri package on my system:
Code: 
mesa-dri-24.1.7_8:
        libxshmfence-1.3.3
        libxcb-1.17.0
        libXv-1.0.13,1
        libXrandr-1.5.4
        libXfixes-6.0.1
        libXext-1.3.6,1
        libXdamage-1.1.6
        libX11-1.8.12,1
        expat-2.7.1
        wayland-1.24.0_2
        spirv-tools-2025.3.r1
        mesa-libs-24.1.7_1
        libdrm-2.4.123,1
        spirv-llvm-translator-llvm19-19.1.10
        llvm19-19.1.7_1
        zstd-1.5.7
The only "extraneous" thing here (at least for me, an Xorg user) is Wayland, but graphics/mesa-dri can be compiled without Wayland support.
RetroComputingCollector said:
I think someone should message the maintainers of all of these ports and ask them if debloating them of their dependencies would be possible. I think all of this Linux dependency garbage should be made optional if possible.
Click to expand...
Well, since you feel this urge who or what prevents you from doing it? Of course, a port flavor would be much more practical than compiling it (that would mean installing all the build dependencies) for users of binary packages.
 
Need flavors of X, one without any Wayland. Also, the X server and X client parts need to keep a split for distinction. In some ports the distinction is split, but it needs to be for everything. We have enough of the structure of the repositories to do that. Anything more, we don't.

If X server and X client metaports are separate, we could limit the flavors of Xorg or Wayland to the X server.

X client port can be standard and be agnostic of Wayland. A lot of ports are needed for basic functions of X client including for window managers, like xrandr, xext, xft, xrender, xinerama. Having some of these dependencies missing changes the functionality of window managers, such as for video output spreading across both monitors, or each one being able to distinguish the boundaries of each monitor to have proper output on each monitor. From an example of a window manager's behavior, to which dependencies are compiled in from a different thread:
sidetone said:
Compile options & functionality
x11-wm/jwm make config options of:
  • JPEG, PNG, SVG or XPM are needed for setting the background image to these file types. Compiling without these settings, doesn't seem to affect icons used in windows and in the task bar. SVG is turned off by default, and it also brings in a lot of unrelated dependencies, when used.
  • XINERAMA adjusts the behavior for maximizing windows on multi-screens. When Xinerama is not compiled into JWM, a maximized window will take up all of two screens. With it compiled in, a maximized window will take up only one screen where it's maximized.
  • XEXT allows the JWM option of noborder to work. noborder removes the border on windows. XEXT is also a core dependency of other JWM options: XINERAMA, XPM, XMU.
  • XFT is for better fonts used in JWM including window bars, and in the task bar. FRIBIDI is for Unicode and for bidirectional text for some written languages. NLS is another option of interest here.
  • XRENDR is a dependency of XFT.
Click to expand...
Those above, with exceptions of image file types, are libx11 dependencies. libxcb has these even more cleaned up. In libxcb, the code to do that which doesn't add to that basic functionality is removed and consolidated into fewer or smaller libraries. libxcb can be worked in easier for window managers than for applications, without breaking dependencies. Lots of libx11 are still needed for window managers and other programs which use Xft fonts for Internationalization, and for multiple languages, because there are lacking libxcb libraries for those purposes. This is relevant to X client.

We do need a lighter Xorg server port, but more importantly, flavors which don't have Wayland. A lot of users who use Xorg, don't use Wayland.
 
Maxnix said:
What junk? These are the dependencies of a stock mesa-dri package on my system:
Code: 
mesa-dri-24.1.7_8:
        libxshmfence-1.3.3
        libxcb-1.17.0
        libXv-1.0.13,1
        libXrandr-1.5.4
        libXfixes-6.0.1
        libXext-1.3.6,1
        libXdamage-1.1.6
        libX11-1.8.12,1
        expat-2.7.1
        wayland-1.24.0_2
        spirv-tools-2025.3.r1
        mesa-libs-24.1.7_1
        libdrm-2.4.123,1
        spirv-llvm-translator-llvm19-19.1.10
        llvm19-19.1.7_1
        zstd-1.5.7
The only "extraneous" thing here (at least for me, an Xorg user) is Wayland, but graphics/mesa-dri can be compiled without Wayland support.

Well, since you feel this urge who or what prevents you from doing it? Of course, a port flavor would be much more practical than compiling it (that would mean installing all the build dependencies) for users of binary packages.
Click to expand...
Having to untangle dependencies like this is a sign that something is deeply wrong. Just think about that. Also, it is Ninja that brings in Python. We should be using the NetBSD Xorg that doesn't have all of that crap.
 
RetroComputingCollector said:
Having to untangle dependencies like this is a sign that something is deeply wrong. Just think about that.
Click to expand...
Depends which ones. Some listed are needed, as you can see in my example above for X clients: Xext, xrandr, libxcb, libx11. Everything else with lib in the dependencies shown is needed. What doesn't belong is Wayland. As for LLVM, it needs to stop being brought in, as it needs to be made code compatible. We need to borrow from NetBSD for that, because their Xorg is built with their their improved BSD toolchain. While LLVM is part of the FreeBSD toolchain, it needs to build with the one from base. I bet NetBSD has that fixed.

I'm aware you said untangled. Though, to make it clear, the distinction that some are needed, for what purposes, and that Wayland doesn't need to be tangled in. That we need to borrow from NetBSD to fix LLVM from ports being pulled in.
 
Python isn't bloat, but for certain ports, it shouldn't be pulled in. If it were PythonBSD, which I'm exaggerating on, then yes, Python should be brought in, bc it's a useful scripting utility to do a lot of what isn't easy in C. Programs need to be built natively or with native programming languages.

If an Operating system's purpose was C with Python, or C with Lua, then, it would make sense to pull in Python or Lua. Even though Lua is in base, that doesn't mean that most common ports should use Lua.
 
I think what would be best is to make Xorg a "quasi-base" component that is optional on install, but still sort of a part of base, kind of like in OpenBSD. This would make oversight much better, and make things easier for users.
 
You must log in or register to reply here.
Back
Top