[MacPorts] #63609: gtk-osx-application-common-gtk2 and gtk-osx-application-common-gtk3 (both @3.0.1) conflict with one another

[MacPorts]

#63609: gtk-osx-application-common-gtk2 and gtk-osx-application-common-gtk3 (both
@3.0.1) conflict with one another
-------------------------------------------------+-------------------------
  Reporter:  cooljeanius                         |      Owner:  mascguy
      Type:  defect                              |     Status:  assigned
  Priority:  Normal                              |  Milestone:
 Component:  ports                               |    Version:  2.7.1
Resolution:                                      |   Keywords:
      Port:  gtk-osx-application-common-gtk2,    |
  gtk-osx-application-common-gtk3                |
-------------------------------------------------+-------------------------

Comment (by cooljeanius):

 Replying to [comment:3 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...

-- 
Ticket URL: <https://trac.macports.org/ticket/63609#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS