gtk-osx-application-common-gtk2 and gtk-osx-application-common-gtk3 (both @3.0.1) conflict with one another

[cooljeanius (Eric Gallager)]

They both try to install a gtkmacintegration/gtkosxapplication.h header:

x ./opt/local/include/gtkmacintegration/
x ./opt/local/include/gtkmacintegration/gtkosxapplication.h
Error: Failed to activate gtk-osx-application-common-gtk3: Image error: /opt/local/include/gtkmacintegration/gtkosxapplication.h is being used by the active gtk-osx-application-common-gtk2 port.  Please deactivate this port first, or use 'port -f activate gtk-osx-application-common-gtk3' to force the activation.
DEBUG: Error code: registry::image-error
DEBUG: Backtrace: Image error: /opt/local/include/gtkmacintegration/gtkosxapplication.h is being used by the active gtk-osx-application-common-gtk2 port.  Please deactivate this port first, or use 'port -f activate gtk-osx-application-common-gtk3' to force the activation.
    invoked from within
"throw registry::image-error "Image error: $file is being used by the active [$owner name] port.  Please deactivate this port first, or use 'port -f ac..."
    ("foreach" body line 45)
    invoked from within
"foreach file $imagefiles {
                set srcfile "${extracted_dir}${file}"

                # To be able to install links, we test if we can lst..."
    invoked from within
"registry::write {
            foreach file $imagefiles {
                set srcfile "${extracted_dir}${file}"

                # To be able to instal..."
    invoked from within
"try {
        registry::write {
            foreach file $imagefiles {
                set srcfile "${extracted_dir}${file}"

                # To be ..."
    (procedure "_activate_contents" line 21)
    invoked from within
"_activate_contents $requested $rename_list"
    (procedure "portimage::activate" line 63)
    invoked from within
"registry_activate $subport $_inregistry_version $_inregistry_revision $_inregistry_variants $optionlist"
    (procedure "portactivate::activate_main" line 20)
    invoked from within
"$procedure $targetname"
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_gtk-osx-application/gtk-osx-application-common-gtk3/main.log for details.
DEBUG: Image error: /opt/local/include/gtkmacintegration/gtkosxapplication.h is being used by the active gtk-osx-application-common-gtk2 port.  Please deactivate this port first, or use 'port -f activate gtk-osx-application-common-gtk3' to force the activation.
    invoked from within
"throw registry::image-error "Image error: $file is being used by the active [$owner name] port.  Please deactivate this port first, or use 'port -f ac..."
    ("foreach" body line 45)
    invoked from within
"foreach file $imagefiles {
                set srcfile "${extracted_dir}${file}"

                # To be able to install links, we test if we can lst..."
    invoked from within
"registry::write {
            foreach file $imagefiles {
                set srcfile "${extracted_dir}${file}"

                # To be able to instal..."
    invoked from within
"try {
        registry::write {
            foreach file $imagefiles {
                set srcfile "${extracted_dir}${file}"

                # To be ..."
    (procedure "_activate_contents" line 21)
    invoked from within
"_activate_contents $requested $rename_list"
    (procedure "portimage::activate" line 63)

This conflict should either be fixed, or marked.

[mascguy (Christopher Nielsen)]

I was just about to create a new ticket for this, as it's definitely a royal pain-in-the-keister.

I'll prioritize this on my backlog, as it's long-overdue to be fixed.

[mascguy (Christopher Nielsen)]

In theory, this potentially may be easy to fix: The integration header is identical between gtk2/gtk3, and can potentially be moved to a shared non-version-specific subport. (Well, it can definitely be shared between gtk2/gtk3; for our eventual addition of gtk4, we'll likely segregate all of this regardless.)

Also, the lib-related items are non-conflicting as well. However, for the latter, we may have issues with gtk2-dependent items trying to opportunistically utilize those for gtk3, when both are installed at the same time. (Not sure yet though, as I'll need to test dependents to see what happens. But definitely a notable gotcha.)

The one definitive sticking point, is the localization data hosted under ${prefix}/share/locale: That completely conflicts between the two, in terms of file locations. And it differs between gtk2/gtk3: The embedded versions numbers are different, and there may be things beyond that too.

The initial conclusion? Based on all of the above, cleanly segregating everything would be the most reliable approach. But that would require changing every gtk2/gtk3 dependent, to search in the new location. And I'd like to avoid that if at all possible, as there are a LOT of dependents. So such an approach wouldn't be used, unless absolutely necessary.

Still analyzing all of this stuff, but definitely making progress. More to follow, after I've done more investigation and testing.

[cooljeanius (Eric Gallager)]

Replying to mascguy:

In theory, this potentially may be easy to fix: The integration header is identical between gtk2/gtk3, and can potentially be moved to a shared non-version-specific subport. (Well, it can definitely be shared between gtk2/gtk3; for our eventual addition of gtk4, we'll likely segregate all of this regardless.)

Also, the lib-related items are non-conflicting as well. However, for the latter, we may have issues with gtk2-dependent items trying to opportunistically utilize those for gtk3, when both are installed at the same time. (Not sure yet though, as I'll need to test dependents to see what happens. But definitely a notable gotcha.)

The one definitive sticking point, is the localization data hosted under ${prefix}/share/locale: That completely conflicts between the two, in terms of file locations. And it differs between gtk2/gtk3: The embedded versions numbers are different, and there may be things beyond that too.

The initial conclusion? Based on all of the above, cleanly segregating everything would be the most reliable approach. But that would require changing every gtk2/gtk3 dependent, to search in the new location. And I'd like to avoid that if at all possible, as there are a LOT of dependents. So such an approach wouldn't be used, unless absolutely necessary.

Still analyzing all of this stuff, but definitely making progress. More to follow, after I've done more investigation and testing.

Could we just nuke the locale stuff entirely? It's not like I use any other locales besides my default one anyways...

[mascguy (Christopher Nielsen)]

Replying to cooljeanius:

Could we just nuke the locale stuff entirely? It's not like I use any other locales besides my default one anyways...

Without doing plenty of in-depth testing of the various dependents, it's difficult to say. So I'm reluctant to make such a change, if there's a chance it will fundamentally break existing ports.

Ultimately, the long-term fix for all of this, involves completely segregating all of these foundational ports. (With separate isolated subports dedicated to Quartz and X11.)

So we'll get there. But it's going to take time, as there's a lot involved with all of this.

[cooljeanius (Eric Gallager)]

This is now blocking the latest inkscape upgrade for me

[Christopher Nielsen <mascguy@…>]

In 0f65c1302d12fc70ecabcac09d0ee5e26d3b68b5/macports-ports (master):

gtk-osx-application: segregate subports, to eliminate conflicts
Fixes: #63609

[Christopher Nielsen <mascguy@…>]

In bd0f6afdb684112a89375b87329232f2446e0c14/macports-ports (master):

gtk-osx-application-gtk2: rev-bump dependents, for new file layout
See: #63609

[Christopher Nielsen <mascguy@…>]

In 5eadabef024a6c6205f6b88bc77fbd3054c1854f/macports-ports (master):

gtk-osx-application-gtk3: rev-bump dependents, for new file layout
See: #63609