geocode-glib @3.26.4: support API version 2

[oleaamot (Ole Aamot)]

geocode-glib-2.0

From ​https://gitlab.gnome.org/GNOME/geocode-glib

While geocode-glib can be compiled against libsoup version 2.x or version 3.x, as those versions can't cohabit in the same binary, you will need to choose which one your application will support, especially if geocode-glib isn't a direct dependency. Version 1.0 of the geocode-glib API only supports libsoup 2.x, version 2.0 (and later) of the API will only support libsoup 3.x.

[ryandesign (Ryan Carsten Schmidt)]

What is the purpose of this ticket? The geocode-glib (3.26.4) port does depend on the libsoup (3.4.3) port. Are you asking for that to change?

[oleaamot (Ole Aamot)]

I just observe that geocode-glib-2.0 dependent packages such as gtk-internet-radio-locator requires geocode-glib-2.0.pc and it is not currently installed on macports 2.8.1.

From ​https://github.com/macports/macports-ports/pull/21484/checks

No package 'geocode-glib-2.0' found

See ​https://gitlab.gnome.org/GNOME/geocode-glib/-/issues/32

[ryandesign (Ryan Carsten Schmidt)]

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.

[oleaamot (Ole Aamot)]

MacPorts 2.8.1 lacks support for "pkgnamesuffix".

See ​https://cgit.freebsd.org/ports/commit/?id=a327a063dab373a65e743d3cd2600e912732739d

[oleaamot (Ole Aamot)]

The solution must be to build geocode-glib-2 with support for geocode-glib-2.0 and leave geocode-glib as it is.

[mascguy (Christopher Nielsen)]

I'll take a look, as some of these dependencies are still a bit in flux.

[mascguy (Christopher Nielsen)]

Replying to oleaamot:

The solution must be to build geocode-glib-2 with support for geocode-glib-2.0 and leave geocode-glib as it is.

Agreed, and the simplest approach might be to simply add a subport for v2. I'll add this to my to-do list.

[oleaamot (Ole Aamot)]

Replying to mascguy:

Replying to oleaamot:

The solution must be to build geocode-glib-2 with support for geocode-glib-2.0 and leave geocode-glib as it is.

Agreed, and the simplest approach might be to simply add a subport for v2. I'll add this to my to-do list.

OK. Any progress on building geocode-glib-2 with support for geocode-glib-2.0? I keep editing locally to build .pkg, but it would be nice to have this officially fixed in MacPorts.