[MacPorts] #68749: geocode-glib @3.26.4: support API version 2 (was: Regarding geocode-glib-2.0)

[MacPorts]

#68749: geocode-glib @3.26.4: support API version 2
---------------------------+----------------------
  Reporter:  oleaamot      |      Owner:  dbevans
      Type:  enhancement   |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.8.1
Resolution:                |   Keywords:
      Port:  geocode-glib  |
---------------------------+----------------------
Changes (by ryandesign):

 * type:  defect => enhancement


Comment:

 Oh.

 I looked a little further, and although geocode-glib does depend on
 libsoup which is at version 3.4.3 as I noted above, which should mean
 according to what you wrote that it is providing API 2, in fact when I
 configure geocode-glib I see this:

 {{{
 Run-time dependency libsoup-2.4 found: YES 2.74.3
 }}}

 And I see, surprisingly, that libsoup depends on the libsoup-2.4 port
 which is at version 2.74.3. So evidently geocode-glib prefers to use
 libsoup 2 if available, and thus API 1.

 If geocode-glib can only support version 1 or 2 API but not both, then we
 can't make everybody happy all the time. If we keep geocode-glib providing
 API 1, then you cannot install gtk-internet-radio-locator; if we change
 geocode-glib to provide API 2, then the ports that are already using
 geocode-glib today will stop working unless they also support API 2. I
 haven't tried to find out if they do.

 If they don't, then the solution probably has to be that we provide two
 geocode-glib ports (or one port with two subports), one which uses
 libsoup-2.4 and provides API 1 and one which uses libsoup 3.x and provides
 API 2. And ideally these ports should not conflict with one another. I
 haven't tried to find out to what extent the geocode-glib build system is
 designed to accommodate this.

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