• Status Closed
  • Percent Complete
  • Task Type Improvement
  • Category ports
  • Assigned To
  • Operating System CRUX
  • Severity Low
  • Priority Very Low
  • Reported Version 3.7
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: CRUX
Opened by alexmat - 22.10.2022
Last edited by tb - 12.09.2023

FS#1924 - QEMU on headless machine

I run qemu on a headless host that doesn't have the xorg repo. With some minor package tweaks qemu builds and runs well. Some of these might be worth considering:

1) xorg-libpixman doesn't need any xorg deps. I suggest moving it to opt, unless there's a reason it needs to be in the xorg repo. Right now I just fetch a copy of the port to avoid syncing the whole xorg repo.

2) Building libxkbcommon requires: -D enable-x11=false. There's actually already a check for wayland, I suggest adding a similar one for xorg-server, which would be helpful anyway for people migrating to a pure wayland setup in the future.

This is what I add: prt-get isinst xorg-server || PKGMK_XKBCOMMON+=' -D enable-x11=false'

3) The qemu package requires a dependency on libxml2. It was probably omited since it gets pulled in from it's current dependency on something from xorg.

4) In order to make it headless I also add: --disable-sdl --disable-opengl. I'm not sure how to make that flexible. Maybe have a qemu-headless package?

None of these issues are a big deal, but I think 1 2 and 3 have no downsides and are easy changes.

Closed by  tb
12.09.2023 05:00
Reason for closing:  Implemented

> I think 1 2 and 3 have no downsides and are easy changes.

One downside of 2 (at least the way jue first tried to implement it) is that some of the ports depending on libxkbcommon will now have to be adjusted, since they previously could assume the presence of all the ports that xkeyboard-config pulled in. beerman discovered footprint mismatches for qt5 and qt6-base, as a result of this change.

Maybe Alexander has tested a less disruptive change. The proposal as written does not provide enough detail to avoid the breakage. libxkbcommon appearing under opt (not xorg) makes it tempting to try disabling the xorg repo for headless hosts, but these repos are too entangled at the moment, for proposal 2 to be implemented as in commit 53af22068196e7e7b88574ec79bd68d1e89a528f.

Just to make sure we're on the same page, libxkbcommon was already in opt before I suggested the check for xorg-server: https://crux.nu/portdb/?a=search&q=libxkbcommon

xorg-libpixman on the other hand is in the xorg repo. My point regarding that was that it could be moved to opt without affecting anything in the xorg repo while allowing things outside xorg access to libpixman

I think this ticket has uncovered some interesting relationships among our ports, as illustrated by today's commits mentioning xkeyboard-config. Thanks for prompting the investigation into making our libxkbcommon port more flexible.

The unstated assumption behind this ticket appears to be: "opt is a collection that extends core, and xorg is a collection that extends further. Hence a user should be allowed to disable the xorg collection without any ill effects." In the early years of CRUX, this reasoning would have made more sense: https://lists.crux.nu/pipermail/crux-devel/2005-May/000918.html

Even at the time of Tilman's retirement, the xorg collection had a narrower scope: https://lists.crux.nu/pipermail/crux-devel/2012-June/004031.html If Alexander's involvement with CRUX dates back to that era, then he might naturally anticipate no major problems after disabling the xorg collection.

But the opt and xorg repositories have been interdependent for the majority of CRUX history. As early as 2008 sepen wrote a tool (repoverify) that explicitly recognized this interdependence: https://lists.crux.nu/pipermail/crux-devel/2008-July/003697.html Looking at the code fragment sepen quoted, you can see that opt ports are allowed to depend on xorg ports, and vice-versa. Disabling any of the three official repos is therefore non-standard practice, with no guarantee that your `prt-get depinst` commands will succeed. The fact that it's possible to get qemu working, with the xorg collection disabled, should not offer any confidence that other opt ports can be tweaked in a similar manner. But today's commits citing xkeyboard-config demonstrate the ingenuity of CRUX maintainers to accommodate non-standard configurations.

tb commented on 09.09.2023 12:37

@Alexander Matviychuk: with the recent changes to qemu, can this ticket be closed? Moving a port out of xorg might be done for 3.8, personally I feel very indifferent about it.

@tb: Good enough for me. I also don't have a strong opinion about port organization

Thanks for the improvements! I'm ok with closing this ticket
tb commented on 12.09.2023 04:59
Thank you


Available keyboard shortcuts


Task Details

Task Editing