xorg-server: auto-select correct version for macOS release, rather than fail with "use xorg-server-legacy instead"

[mascguy (Christopher Nielsen)]

Presently, this port fails to install on macOS 10.10 and earlier, with the error "xorg-server requires macOS 10.11 or later. Please use the xorg-server-legacy port instead."

This isn't user-friendly, and there's no reason the port can't gracefully select an older release if necessary. Furthermore, it complicates dependent ports: The fallback logic that arguably should be encapsulated in this port, is necessary in every dependent.

[kencu (Ken)]

There was a big discussion when virt-manager put a dep on xorg-server about why that would not be a very good idea.

At the time, I will admit I was in favour of the idea, in general.

Now however, I have changed my tune, and I am no longer in favour of that idea. The upstream XQuartz project has come alive again, and that is really the xorg-server that many people will use.

For MacPorts there are three xorg-servers to choose from. Tiger still needs yet a different one compared to xorg-server-legacy, as there are parts missing from legacysupport still to support xorg-server-legacy on Tiger.

Short story:

Removing the dep in virt-manager for xorg-server is the proper course of action here.

Then don't try to put a bunch of complicated logic into xorg-server to select an xserver. The current message is fine.

[kencu (Ken)]

The only dependants for xorg-server are "xorg", and "virt-manager".

"xorg" is fine to leave.

"xorg-server" should be removed as a dep from "virt-manager" now, as things have changed since it went in.

[mascguy (Christopher Nielsen)]

Well, depending on xorg isn't going to work either, because it's dependent on - drumroll, please - xorg-server.

Perhaps there should be fallback logic in that port then?

[mascguy (Christopher Nielsen)]

Either way, I'm surprised that there's pushback on this. It's absolutely NOT user-friendly, and would be trivial to fix.

Heck, the amount of time spent on this ticket, is such that I could have implemented - and tested - fallback in xorg-server.

[mascguy (Christopher Nielsen)]

Ken, you generally are a strong advocate of graceful auto-fallback. I recall such a discussion with Mame, for example.

So why aren't you advocating for it here...?

[jmroot (Joshua Root)]

Ken's point is that no other X11-based port depends on xorg-server. Users might have Xquartz installed or might even be installing on a headless box and intending to use an X server on another machine. Just removing the dependency here is fine.

[mascguy (Christopher Nielsen)]

Replying to jmroot:

Ken's point is that no other X11-based port depends on xorg-server. Users might have Xquartz installed or might even be installing on a headless box and intending to use an X server on another machine. Just removing the dependency here is fine.

Beautiful, I'll remove that dependency then. Thanks Josh!

[Christopher Nielsen <mascguy@…>]

In 589945a5ed0004f4b72294a899c791f1c78b080c/macports-ports (master):

virt-manager: remove dependency xorg-server

• Closes: #63050

[jmroot (Joshua Root)]

You don't have to consider the ticket closed based on that change though. It's up to Jeremy if he wants to structure the xorg-server* ports the way you describe. There is precedent with ports like ld64.

[mascguy (Christopher Nielsen)]

Replying to jmroot:

You don't have to consider the ticket closed based on that change though. It's up to Jeremy if he wants to structure the xorg-server* ports the way you describe. There is precedent with ports like ld64.

Good point. We're also using the auto-fallback technique for a few other popular ports, including wireshark3:

​https://github.com/macports/macports-ports/commit/3fc0e042540c4a9db088fbb84f4ab292eafe3c0d