`osgeo-*` formulas should not fail to install if homebrew-core `gdal`/`proj` is linked

[pat-s]

If one switches to homebrew-core gdal or proj and some osgeo-* formulas are about to be updated, the linking step fails and the installation is marked as not completed.

Hence, on every brew upgrade call the installation is attempted again, queuing up the osgeo-formulas unless osgeo-gdal is linked again.

This seems odd and just came up recently, judging from my usage experience. Can the osgeo formulas not link against the keg-only osgeo-gdal?

Upgrading osgeo/osgeo4mac/osgeo-postgis 3.0.1_6 -> 3.0.1_7
osgeo-proj: You have other linked versions!

Unlink with brew unlink proj or remove with brew uninstall --ignore-dependencies proj

osgeo-gdal: You have other linked versions!

Unlink with brew unlink gdal or remove with brew uninstall --ignore-dependencies gdal

Error: osgeo-postgis: Unsatisfied requirements failed this build.

[alazarolop]

Hi @pat-s , I think these requirements were set to guarantee a consistent installation, primarily to QGIS.

Don't you think they make sense in this case? If you are using this PostGIS version, you need OSGeo GDAL and Proj linked to get it works properly. If you are not, should you uninstall it until next time? An advantage of the tap is the ability to combine the latest versions of PostGIS at any time, so you don't risk much uninstalling it. What is your use case? You can also pin the formula, so you make it skip the upgrade, and you keep it.

[pat-s]

Sure, consistency using a common build chain is always good and makes things easier. I am not saying that gdal should be used instead of osgeo-gdal but there should be a way to use osgeo-gdal even if gdal is linked?

It seems that many (all?) formulas from the osgeo4mac tap rely on osgeo-gdal and osgeo-proj being linked instead of just installed.

I want to use homebrew-core gdal and proj (various reasons) but also be able to install, run and update osgeo4mac formulas. This was at least possible at some point - currently its conflicting.

In the end its about paths - so osgeo4mac formulas would need to do some internal path manipulations if gdal is linked instead of osgeo-gdal?

[alazarolop]

Yeah, I understand what you mean.

1. About the warning. They come from some code lines in the formulas, so they could be erased. But, even if one gets rid of them, I wouldn't assume a good behavior from the formulas when some dependencies aren't linked.
2. In this sense, I think you are looking for a kind of keg_only, so the formula, e.g. osgeo-postgis, would point directly to the installed dependency, e.g.osgeo-gdal directory, rather than linked files. To be honest, I don't know how "some internal path manipulations" could be tackle nor if it's allow by formulas, but I would be glad to help with a PR. Would you have any suggestion to begin with? I mean, what formula are you interested in the most?

[pat-s]

Maybe let's tackle this the other way round: what is different in osgeo-gdal compared to gdal? Besides answering in this issue, this information could also go into the README here? I assume strong reasons since otherwise things could be simplified by just relying on homebrew-core gdal?

If the restrictions are that some options are not activated in gdal, this could maybe be solved by a PR th the gdal formula? Just brainstorming though.

In this sense, I think you are looking for a kind of keg_only, so the formula, e.g. osgeo-postgis, would point directly to the installed dependency, e.g.osgeo-gdal directory, rather than linked files.

Yes, at least for some dependencies. This could be noted in the formula info then.

I mean, what formula are you interested in the most?

No particular one, I do not use them in my daily work. I need to run some project scripts in R from time to time (SAGA, GRASS, other spatial libraries) and therefore I would like to have a robust spatial stack installed via homebrew. Installing all the GUI software by hand is a pain :) However, since I do not use/need them so urgently, I cannot really invest a lot of (any) time into contributing right now. And my free time is already occupied with my PhD right now :/

[alazarolop]

@pat-s No worries about code contributing, I think this thread is also helping to improve to the tap. I also want to keep "a robust spatial stack installed via homebrew" as I use them in my daily routine.

I assume strong reasons since otherwise things could be simplified by just relying on homebrew-core gdal?

Tap versions are intended to be more flexible and provide more functionality than those available as core versions too. For example, GDAL in the tap works with a wider range of formats as HDF4, FileGDB, OpenJPEG or MySQL. The reason for an alternative PROJ version is control for other software compatibility, e.g. GRASS or R packages, it doesn't add any option AFAIK. Apart from these core formulas, PostgreSQL include the PL/Python extension.

If the restrictions are that some options are not activated in gdal, this could maybe be solved by a PR th the gdal formula? Just brainstorming though.

Some of the formulas aren't available in core (HDF4, FileGDB API) and I'm not sure how it could work with their policy of dependency simplification. I haven't tried though, but it would be interesting.

All of these come from my understanding, I'm learning how to compile and maintain / manage software on the way to be honest.

[stale[bot]]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want to keep the issue open, please comment or update the info here. Thank you for your contributions.

[stale[bot]]

This issue or pull request has been automatically closed because it has not had recent activity. Thank you for your contributions.