Well, this isn’t working out.  With the little time I have these days to spend on packaging GDAL, QGIS and PostGIS, it’s taken me this long to get stuck one too many times.  I can’t keep packaging software.  I still use QGIS, GDAL and PostGIS in my work, and I do have GDAL and PostGIS working, but I’ll be using the “official” QGIS package and just building GDAL and PostGIS for my job without a public package.

Sorry.  It’s been fun, mostly.

The past year, and especially the past 6 months, has been crazy, and I haven’t had time for packaging software.  With that and other lapses over the past few years, I’ve decided to slow down.  I still use the software at my job, this will be the main focus.  I’m starting to catch up, but I only have a vague ETA of before the end of the year, hopefully.

This is what I have in mind:

• System

Immediately, I will bump the minimum to macOS 10.14 Mojave due to a change in one of the GDAL dependencies.  In the future I may bump the minimum again in the middle of a major GDAL or QGIS release.

I don’t know what I will do with M1.  I don’t have an M1 Mac yet for development, though I do have access to one for testing.  QGIS may take a while anyways because a new Qt version is needed, and a QGIS update for that is in progress.

• GDAL Complete

I will try to keep this up to date, independent of the QGIS version, so it could change in the middle of a QGIS major version.

• QGIS

I will package only the LTR version.  It looks like the releases will slow down so this works well with my plan.  Qt could be a problem due to licensing changes and changing system support.  It’s possible I could change Qt versions in the middle of a QGIS release.

• Postgres/PostGIS

Low priority for updates.  I’ll package them as time permits.

Holiday present for all.  QGIS 3.16.2 (future LTR) is totally rebuilt with updated internals.

• Latest Qt 5.15
• GDAL 3.2
• PROJ 7.2

It now finds internal GRASS, OTB and SAGA. and external GDAL and Python without fussing with path settings.  See the readme for instructions to clean up old settings.

With QGIS 3.16 I bumped the minimum macOS to 10.13 High Sierra.  I’ll probably maintain this through it’s LTR life.

QGIS is updated to v3.10.7 LTR & 3.14.0 and GDAL Complete is updated to 3.1.1.

NOTE: PDF read support is not included in GDAL/QGIS yet.  I’m working on it.  It will be built into GDAL this time due to the licensing difference in the new base PDF library, but is difficult to get built properly.

NOTE: In attempting to update GDAL on an old Mac I discovered that it does not work on Sierra.  I’m sure I have all the options set to enable it on Sierra, but it’s possible the updated Xcode on my development Mac has a bug with this.  If this is the case then I will not be able to fix it and I will have to bump the system requirements to High Sierra.  By dependency, this affects QGIS, PostGIS and pgRouting.  It’s likely Postgres is also affected directly.

UPDATE: The QGIS 3.14 installer was not configured correctly and overwrote QGIS LTR.  Now fixed.

UPDATE 2: I think I figured out the Sierra crash problem – it was really an old hardware problem, now should be fixed.  System requirements now back down to Sierra.

Finally caught up.

The GDAL Complete framework package gets a full update of all components, including the primary GDAL framework updating to 3.1.  Python support updated to Python 3.8.  The Sqlite/Spatialite/Rasterlite framework has been split into separate frameworks because of new interdependencies.

Postgres is now at v12.3.  PostGIS is updated to 3.0.1.

QGIS updated to the latest 3.10 LTR and 3.12 current versions.  Some packaging issues have been ironed out. I will be keeping my separation of QGIS, GDAL and Python.

There may be problems installing or using my packages on macOS Catalina.

I don’t have a new enough Mac to install Catalina on.  But this is what I’ve read about so far:

Installers must now also be notarized, in addition to the signing.  While signing is something the developer does, notarizing is done by Apple.  Both require a paid developer account, which I do not and probably will never do.

Running/allowing installations is pretty much the same, the notarization check can also be bypassed by using “Open” from right-clicking an installer package.

There are huge changes to the file system, though they are transparent to the user.  Mainly, the system is now locked off in a read-only part of the file system.  I think most of my installers are OK with this.  Postgres, PostGIS and pgRouting may have problems, as they are installed in a part of the system that may not be accessible.

There are also new access provisions – there may be a lot of alerts popping up asking to allow access to parts of the file system.

Well, my QGIS build is now an official alternate build, and the download hosting returns to my site.  It seems many people think an all-in-one drag-n-drop installation is THE correct method of Mac app installation.  I’ll keep doing my build my way as long as I have the energy and interest (hopefully for a long time).

There may be some changes.

• I’ll keep the separate components installation (ie outside the QGIS app) – I especially use GDAL extensively in the Terminal and Automator and with python.
• I don’t know yet if I’ll keep everything on one disk image, but at least I’ll probably separate GDAL back into its own installer, that’s easier to maintain.
• I’m thinking about externalizing GRASS for Processing.  Probably using the official GRASS app.  Direct GRASS data access would still use an internal GRASS, but it will only be enough for data access, maybe combined with the GDAL GRASS plugin.  Maybe this will help it actually work.  Though, the GRASS app is also all-in-one, adding to the duplication bloat.  GRASS is a very low priority for me.

I need to work on some major updates – GDAL 3, PROJ 6, Postgres/PostGIS.

Postgres finally updated to 9.6, along with the PostGIS (to 2.4.5) and pgRouting (to 2.6.1) extensions. As with the rest of the recent packages (GDAL, QGIS), minimum macOS 10.10. That includes the transition PostGIS and pgRouting for for Postgres 9.4, because of C++ needs for pgRouting.

This is a major upgrade, see the upgrade readme on the disk image for details. A quick summary from Postgres 9.4 to 9.6 in place:

1. 1. Upgrade your system to at least 10.10 Yosemite
   2. Update PostGIS and pgRouting extensions (if installed) to the transition versions made for Postgres 9.4, including running extension updates on your databases
   3. Update Postgres to 9.6 plus the same-version extensions made for PG 9.6
   4. run pg_upgrade