core: Create an X.Org requirement.

[rwhogg]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully ran brew tests with your changes locally?

The existing X11 requirement only works for OS X, and works in concert
with XQuartz. For Linux, we want to install upstream X.Org instead.

[sjackman]

In this case I think it may be more clear to copy and paste the small handful of necessary functions from X11Requirement into XorgRequirement rather than inherit from X11Requirement. We can't really compare the minimum XQuartz version requested by the formula to our X.org version unless we create a fancy mapping table, so the comparison will probably just return that it's always satisfied regardless of the requested version. Oh, but that breaks the brew tests I bet if it always returns satisfied. Hmm.

[sjackman]

Is it possible to not modifyx11_requirement.rb at all?

[rwhogg]

Is it possible to not modify x11_requirement.rb at all?

From the looks of it, yes!

[rwhogg]

The way I see it, we're trying to depend on the host system as little as possible and the assumption is going to be that linuxbrew/homebrew-xorg/xorg is going to be the canonical supplier of X11. So for all intents and purposes we "know" what the version of X.Org is.

With homebrew/gui, homebrew/x11, and (Linuxbrew's) homebrew/core tapped, there is exactly one formula that (directly) depends on a specific X11 version, and it's gv.

$ ag "depends_on.*x11.*=>.*\""
homebrew-x11/gv.rb
15:  depends_on :x11 => "2.7.2"

[rwhogg]

With this in mind, I'm hesitant to introduce any version checking on X.Org. Currently, the version is coming up as "0.0.0", which could be worse, I guess.

We could introduce some version number into it, based on either the upstream release numbers or BLFS', but that would make updating X.Org a pain since it would be in a different repository than this requirement or any tests for it.

[sjackman]

I suggest using the version number of the xorg virtual package, which is the date that it was last updated. The format is currently 20160314, which is fine by me. We could also make it 2016.03.14 to match the typical triple decimal version format. I don't have a real preference.

[sjackman]

With this in mind, I'm hesitant to introduce any version checking on X.Org. …
So for all intents and purposes we "know" what the version of X.Org is.

Yep, I agree. I don't think any version checking is needed.

[sjackman]

I'd prefer one of either

if OS.mac?
    assert_instance_of X11Requirement, find_requirement(X11Requirement)
else
    assert_instance_of XorgRequirement, find_requirement(XorgRequirement)
end

or

req = OS.mac? ? X11Requirement : XorgRequirement
assert_instance_of req, find_requirement(req)

with a preference for the latter (untested code). I'm not sure the latter is actually legal code. Guess we'll find out.

[sjackman]

Looking good! I'm glad to see that the tests are passing.

[rwhogg]

this means that we chop out the version number for compatibility with X11Requirement, but we don't store it since the XQuartz version numbers are meaningless on Linux.

[sjackman]

Sounds good.

[sjackman]

Looking good, Bob! This patch is just about ready to merge.

[sjackman]

👍 Nice! Thanks, Bob.

Should we bottle up X11 before merging this, to give a better user experience and since this pulls in like 70 formula? Are the X11 library bottles cellar :any?

[rwhogg]

Should we bottle up X11 before merging this, to give a better user experience and since this pulls in like 70 formula?

Yes, definitely. I'll submit the first batch tonight.

Are the X11 library bottles cellar :any?

Guess we'll find out! My hunch is "no" but we'll see.

[sjackman]

It would be great if they could be cellar :any. They won't be if they look in a fixed location for config files or other resources that is specified at compile-time.

[rwhogg]

Marking as blocked by maxim-belkin/homebrew-xorg#21, but it's a soft-block.

Also note that I'm going to want to sanity-check this one last time before merging.

[maxim-belkin]

I'd suggest a more descriptive message. Maybe something like something like:
X.Org is required to install this formula. Use: brew tap linuxbrew/xorg && brew install xorg

[sjackman]

Since there is a default_formula defined, I believe this message won't ever be displayed. I didn't catch that before. This method def message can be removed entirely.