Add keyword to list compatible graphical environments (X11, Quartz, Wayland)?

[c.herbig@…]

Although some ports list variants like ±x11 and +quartz, some of them don't because the quartz compatibility is handled by a dependency. For example, Gnumeric is +quartz compatible because it is handled by the gtk+quartz dependency, yet there is no indication in the port file that +quartz is an option for gnumeric.

So rather than making a variant in the portfile that does nothing other than to list itself in port info, perhaps it would be wise to make a new keyword (graphics_env ?) that lists the environments that the port is known to work with. If nothing is specified, then assume X11. It is not ok to assume that just because the gtk dependency has been compiled for +quartz that the app is though; as of the writing of this, gnome-chemistry-utils fails to build in a +quartz environment due to some X11 specific OpenGL code.

Although there aren't many to choose from right now, just X11 and quartz, this may become more relevant over the next year as Wayland picks up steam and packages are modified to take advantage.

[cooljeanius (Eric Gallager)]

Cc Me!

[cooljeanius (Eric Gallager)]

as Wayland picks up steam and packages are modified to take advantage

Wayland hasn't been ported to MacPorts yet though... actually does it even run on Darwin at all yet?

[c.herbig@…]

Replying to egall@…:

as Wayland picks up steam and packages are modified to take advantage

Wayland hasn't been ported to MacPorts yet though... actually does it even run on Darwin at all yet?

I don't know, but I assume that eventually it will be over the next year or so as linux distros also start to use it to displace X11. Anyway, I only mentioned Wayland as an example of how creating such a keyword could also be useful in the future. In the present I'm only concerned with trying to increase the visibility of +quartz an an option (or ensuring that people see it is not an option for ports that are not yet compatible with it).

[larryv (Lawrence Velázquez)]

Replying to c.herbig@…:

Although some ports list variants like ±x11 and +quartz, some of them don't because the quartz compatibility is handled by a dependency. For example, Gnumeric is +quartz compatible because it is handled by the gtk+quartz dependency, yet there is no indication in the port file that +quartz is an option for gnumeric.

Does gnumeric actually build differently depending on whether gtk is built +quartz or +x11? It is not acceptable for port install FOO to produce different results based solely on whether a dependency BAR is installed +baz or -quux or anything.

If this is the case, variants need to be added to gnumeric to make its builds reproducible. Each variant would use the active_variants-1.1 PortGroup​ to ensure that gtk is built with the necessary variant. For an example of this idiom, see the pango Portfile’s +quartz variant​. The PortGroup itself also has rudimentary documentation on usage.

If some degree of intelligence is desired, I believe it is possible to check whether a particular dependency is installed with a particular variant, and set default_variants accordingly.

So rather than making a variant in the portfile that does nothing other than to list itself in port info

The variants should not do nothing. They should check for the presence or absence of the relevant dependencies’ variants, as I described above.

perhaps it would be wise to make a new keyword (graphics_env ?) that lists the environments that the port is known to work with. If nothing is specified, then assume X11. It is not ok to assume that just because the gtk dependency has been compiled for +quartz that the app is though; as of the writing of this, gnome-chemistry-utils fails to build in a +quartz environment due to some X11 specific OpenGL code.

If gnome-chemistry-utils requires its dependencies to be built as -quartz, it should use active_variants-1.1 to enforce this.

Given that one can (sort of) enforce variant selection on dependencies, I don’t see how a new Portfile option meaningfully changes the situation here.

[c.herbig@…]

Replying to larryv@…:

Does gnumeric actually build differently depending on whether gtk is built +quartz or +x11? It is not acceptable for port install FOO to produce different results based solely on whether a dependency BAR is installed +baz or -quux or anything.

I don't think so, I thought that gtk was supposed to handle all of the compatibility backends (except OpenGL).

The variants should not do nothing. They should check for the presence or absence of the relevant dependencies’ variants, as I described above.

I agree, it would be very silly to have a a variant that does nothing, but is only there to advertise that the port is capable of being run in a +quartz environment.

If gnome-chemistry-utils requires its dependencies to be built as -quartz, it should use active_variants-1.1 to enforce this.

I didn't know you could do that, I might look at it more later.

Given that one can (sort of) enforce variant selection on dependencies, I don’t see how a new Portfile option meaningfully changes the situation here.

Perhaps I am not expressing myself correctly. The idea was not to create a keyword to modify the configuring or building process, it was simply to make a tag that could show up via port info portname that would list the graphical environments the port is known to work with; nothing more than a way to advertise to the user.

[c.herbig@…]

Let's back up a bit. Here is the problem (though a small one) the way I see it, with gnumeric as an example:

port info gnumeric

gnumeric @1.10.17, Revision 4 (gnome, math)
Variants:             python25, python26, [+]python27, universal

Description:          A spreadsheet with GNOME support.
Homepage:             http://projects.gnome.org/gnumeric/

Extract Dependencies: xz
Build Dependencies:   gnome-doc-utils, intltool, pkgconfig
Library Dependencies: desktop-file-utils, rarian, goffice08, libglade2, libpng,
                      py27-gobject
Runtime Dependencies: yelp
Platforms:            darwin
License:              GPL-2
Maintainers:          nomaintainer@macports.org

There is no indication at all that gnumeric is compatible with a +quartz environment, unless you already happened to know that it is. This is because the gtk dependency is what handles all of the +quartz stuff. However, some sort of keyword, such as graphics_env, could be appended to the portfile to proclaim this to the user, so that port info would give this:

gnumeric @1.10.17, Revision 4 (gnome, math)
Variants:             python25, python26, [+]python27, universal
Graphics_env:     X11, Quartz

Description:          A spreadsheet with GNOME support.
Homepage:             http://projects.gnome.org/gnumeric/

Extract Dependencies: xz
Build Dependencies:   gnome-doc-utils, intltool, pkgconfig
Library Dependencies: desktop-file-utils, rarian, goffice08, libglade2, libpng,
                      py27-gobject
Runtime Dependencies: yelp
Platforms:            darwin
License:              GPL-2
Maintainers:          nomaintainer@macports.org

Thus the user would know that it is in fact an option to use port install gnumeric +quartz. In the future, once Wayland is more common, it could also be proclaimed in the portfile. Currently though, the only way to display a port's compatibility with +quartz is to either add it to the long_description or to create a variant that does nothing, which as mentioned above is rather silly.

Now, a solution that won't work: recursively append the variants of dependentcies to the list of variants on the port file. That is to say, it is not ok to look at gtk and see that it has a +quartz and then simply append it to the description of gnumeric. Why? There are some ports, gnome-chemistry-utils for example, that compile fine with X11, yet will fail with +quartz, even though gtk was compiled +quartz. This is because some ports have direct X11 calls and includes in them, <gdk/gdkx.h> seems to be a common culprit. So, you can't just assume that because the deps work with +quartz that the final program will. This can be a rude surprise to someone who has been waiting hours for their requested ports to compile, and is suddenly left without.

The reason I am so interested in this is because I feel very strongly that +quartz is a great feature for the end user, and is a great feature that sets MacPorts apart from Fink (unless they have added this in the last year) and Homebrew. So, I'm not saying that my solution is the only way to do it and that it has to be implemented by next tuesday, but that I would like to encourage thought and discussion to be given in how to improve the visibility of the +quartz option.

[cooljeanius (Eric Gallager)]

is a great feature that sets MacPorts apart from Fink (unless they have added this in the last year)

The way Fink handles it is that their regular packages support X when relevant, and then they also have "nox" versions of those packages that remove X support, which conflict with the regular versions of those packages. (This confused me for a while, as I thought that "nox" was pronounced "knocks" at first, but now I'm pretty sure it's actually "No X"...) To put it in MacPorts terms, they use the equivalent of conflicting sub-ports to determine X support, while MacPorts uses variants.

[c.herbig@…]

Replying to larryv@…:

The variants should not do nothing. They should check for the presence or absence of the relevant dependencies’ variants, as I described above.

The Inkscape port seems to do just that:

variant x11 conflicts quartz {}
variant quartz conflicts x11 {}

if {![variant_isset quartz]} {
    default_variants +x11
}

[larryv (Lawrence Velázquez)]

Replying to c.herbig@…:

The Inkscape port seems to do just that

The Inkscape port is wrong. Its build would fail if gtkmm had been previously installed with incompatible variants.

[c.herbig@…]

Replying to larryv@…:

The Inkscape port is wrong. Its build would fail if gtkmm had been previously installed with incompatible variants.

This is now making me think that maybe it's not that another metadata keyword will solve the problem as I see it, but rather that there should be a mechanism for showing in port info NAME not just the port's own variants, but also the variants that its dependencies have. Sort of like an rdeps but for variants.