postgis pgrouting: add support for postgresql@15 and postgresql@16

[AndreasA]

@SMillerDev and @cho-m

This should add postgresql@15 and postgrsql@16 support for pgrouting and postgis, if I understand the formulaes correctly.

Extended the provided functionality of https://github.com/Homebrew/homebrew-core/pull/192064

[github-actions[bot]]

Thanks for contributing to Homebrew! :tada: It looks like you're having trouble with a CI failure. See our contribution guide for help. You may be most interested in the section on dealing with CI failures. You can find the CI logs in the Checks tab of your pull request.

[botantony]

There's no need to test all possible version, we can just use one or two

[AndreasA]

@botantony I have set 15 and 16 to ":build" only now.

[SMillerDev]

I disagree, if we expect this to work it should be tested.

[AndreasA]

@SMillerDev @cho-m

I have now done some debugging why postgis for 16 and 15 fails and it seems that the formulae for

postgresql@16 uses a different lib directory in comparison to 17 and 14:

https://github.com/Homebrew/homebrew-core/blob/master/Formula/p/postgresql%4016.rb#L95 https://github.com/Homebrew/homebrew-core/blob/master/Formula/p/postgresql%4017.rb#L103

See also pg_config output:

/opt/homebrew/opt/postgresql@17/bin/pg_config --libdir
Result: /opt/homebrew/lib/postgresql@17

whereas for 16 (and 15)

/opt/homebrew/opt/postgresql@16/bin/pg_config --libdir
Result: /opt/homebrew/opt/postgresql@16/lib

Should I change the postgresql@16 and postgresql@16 formulae to use the same lib dir as with 14 and 17 or should I try to install postgis in the postgresql@16 path?

However, for the second I get a sandbox error during the install locally (though not sure why as it should still be inside the sandbox path?).

[AndreasA]

@SMillerDev @cho-m

I have now adjusted postgresql@15 and postgresql@16 to use the same make / configure logic as postgresql17.

I was now able to install / build and test postgresql@16 / postgresql15 and postgis and pgrouting locally successfully. Hopefully, the pipeline agrees.

However, I am not sure if we can just change the lib paths etc. without creating problems with existing installations (or if we need some migrations)? Or is there another solution but trying to change the install path of postgis resulted in a sandbox error for me locally

[SMillerDev]

However, I am not sure if we can just change the lib paths etc. without creating problems with existing installations (or if we need some migrations)? Or is there another solution but trying to change the install path of postgis resulted in a sandbox error for me locally

We can not, those are set up like this intentionally to avoid conflicts with other postgres installs.

[AndreasA]

However, I am not sure if we can just change the lib paths etc. without creating problems with existing installations (or if we need some migrations)? Or is there another solution but trying to change the install path of postgis resulted in a sandbox error for me locally

We can not, those are set up like this intentionally to avoid conflicts with other postgres installs.

@SMillerDev @cho-m

That should not be an issue as the paths are

/opt/homebrew/lib/postgresql@17 and /opt/homebrew/lib/postgresql@16 etc. So the version is in the path.

Therefore, there should not be any conflicts. postgresql@14 and postgresql@17 both use /opt/homebrew/lib as prefix already. with the version. So that works fine.

The only issue is previous installations that used the opt_lib path.

But if you have an idea to get postgis and pgrouting to install to the opt_lib for 15 and 16 with the original paths, I would be happy to change that part.

The main issue I had was that I ran into sandbox errors - if I changed the path to the opt_lib path - as make install calls install with the opt_lib path which seems to fail because of the sandbox.

[AndreasA]

@SMillerDev @cho-m However, independent of that, changing those formulaes seems to break something with the linux builds (not sure why), so I hope one of you has an idea to get postgis / pgrouting to install in the expected path for postgresql@16 and postgresql15 without needing to change those formulae and just needing to change postgis and pgrouting formulae.

see comment https://github.com/Homebrew/homebrew-core/pull/224072#issuecomment-2894375526

[AndreasA]

@SMillerDev @cho-m

I have now done some more research into the brew recipes, limitations etc. and finally understand how the sandbox part works.

It allows access to various folders which are different per recipe. Some are always accessible like the current versioned lib folders used by postgresql@14 and postgresql@17 as they are outside the formulate itself but they are still versioned.

However, postgresql@15 and postgresql@16 currently use opt_lib which is inside the recipe folder and another recipe does not have access to it. Currenlty postgresql does not have an option to change the used extension folders or similar (I read that it might be possible that v18 adds that feature), so postgis is not able to register the extension without changing the recipes for postgresql@16 and postgresql@15 to work similar to postgresql@14 and postgresql@17.

Personally, I don't see a huge reason against changing the paths similar to postgreql@14 and postgresql@17 as the logic is already in use for those two version.

However, I am not sure how to "fix" previous installations. I guess they would require a reinstall.

I have also checked the previous failing pipeline with Linux and that seems to be some audit error with a Makefile with an extension that I do not have. I guess it might be Linux related but not sure how I would create that audit locally. Also I think that error should then also exist with postgresql@14 and postgresql@17 as those formulae basically do the same. Is it a relevant error? If so, how can I fix it? Or can I ignore it, or add some exclusion for it?

[AndreasA]

@SMillerDev @cho-m Sorry for another notification, but I was now able to fix the remaining pipeline issue. I did not notice beforehand that postgresql@15 hat a Linux only condition at the end of the formulae, as v16+ does not need it anymore.

I added it again and now everything seems to work fine.

Regarding lib directory change, I think it probably does not need any migration and should be fine because:

• It is still specific to the formulae as postgresql@14 and postgresql@17 use it already and can be used at the same time. The name is still part of it, the location has changed, so installing multiple versions at the same time should be fine.
• Existing postgresql@15 and postgresql@16 installations will use the wrong lib until an update. However, postgis and pgrouting was not available for those versions beforehand anyway, so they do not lose any functionality.
• After an update and probably also a reinstall or new installation, the lib directory will be moved. However, it is basically provided with files by homebrew and does not contain configuration files or data, so moving it should not be an issue, even if it is not migrated.

But if necessary, I could probably move the content of the current lib folder to the new lib folder during install (if it exists) but due to the points I mentioned, I think it is probably not necessary.

However, let me know if I should change anything.

[SMillerDev]

I don't think we want to change the directory structure to support postgis. But I'll defer to @MikeMcQuaid who did the work to get it to the current structure.

[AndreasA]

@SMillerDev If there is a solution without modifying the paths I would be happy to use it, as I prefer not needing to change the other recipes.

The only other solution I thought about would be to add a caveat that is show if postgresql@15 and/or postgresql6 is installed that one has to symlink the postgis library files to the correct folder (could probably be one ln command per version).

and skip the tests for those two versions - as I don't think I can create that symlink in the recipe (even during the test).

but it would be a less invasive approach and should work - in theory.

[AndreasA]

Hi @MikeMcQuaid

OK, so first things first:

• postgresql@16 etc. can still be installed (with the changes) at the same time, as it actually uses /opt/homebrew/lib/postgresql@16 etc. as lib directory. As postgresql@14 already does, e.g. /opt/homebrew/lib/postgresql@14/lib. Same with data directory etc.
• postgresql@14 and postgresql@17 already behave like the changes I added for postgresql@15 and postgresql@16
• If I use opt_lib to install the files I have the issue that postgis/pgrouting cannot access it currently as it is outside the sandbox, that is actually my main issue. Otherwise I would not touch the postgresql formulae at all.

So, how would I be able to install postgis into the opt_lib directory? I guess I could add an exception to the sandbox in brew core? If so, I can create a corresponding PR - though not sure how I would test this locally.

then I would not touch the current postgresql formulae at all and just change the install directory here for 15 and 16.

As this is my first PR, I will definitely need some pointers but first I need to be sure in which direction I should change things.

[MikeMcQuaid]

• postgresql@16 etc. can still be installed (with the changes) at the same time, as it actually uses /opt/homebrew/lib/postgresql@16 etc. as lib directory. As postgresql@14 already does, e.g. /opt/homebrew/lib/postgresql@14/lib. Same with data directory etc.
• postgresql@14 and postgresql@17 already behave like the changes I added for postgresql@15 and postgresql@16

Wonderful!

• If I use opt_lib to install the files I have the issue that postgis/pgrouting cannot access it currently as it is outside the sandbox, that is actually my main issue. Otherwise I would not touch the postgresql formulae at all.

Ok, that makes total sense, I understand now. I agree given that that you should not install there.

From my perspective: I'm 👍🏻 here but interested what @cho-m thinks (particularly around whether this will help unblock changing the default PostgreSQL version in Homebrew).

[AndreasA]

@MikeMcQuaid Great. Thanks for the feedback and I will wait for feedback from @cho-m

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[AndreasA]

@SMillerDev @MikeMcQuaid @cho-m Any news if this can be merged or needs changes?

[MikeMcQuaid]

@AndreasA Sorry for the delay! Let me do some chasing up here!

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[AndreasA]

@MikeMcQuaid Still no news regarding this?

[AndreasA]

@carlocab Well just let me know either way, If it won't be done, I will close the PR and otherwise I might need to rebase it.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[AndreasA]

currently don't have time for it, might create one again if I have time - especially as I am not that well versed with brew code, so everything takes way longer than I hope (especially testing everything).