Created attachment 1242773 [details]
Better optional depenedcies management
Description of problem:
Given that gdal is built with a lot of optional dependencies, it would be nice to be able to easily change the dependencies to build the package with in case one does not need gdal to use every library there is.
This should also make managing the differences of gdal's .spec files between Fedora and EPEL easier.
Porposed patch against rawhide attached
Hi, I am comparing epel7 and fedora rawhide spec. The difference in configure parameters consist of python3, libkml and libjson-c. You are proposing introduction of 25 different parameters. Do you really expect compilation without jpeg or curl support?
My primary aim was to allow for a better control of the dependencies in those cases where size of the rpm (and the number of its dependencies) is of major importance. The EPEL use case was only secondary to that.
For example, were you to use gdal in a MySQL Docker image you probably will not need support for either PostgreSQL or SQLite/Spatialite. Similarily to this, if you are only interested in working with vector-based formats, gdal's ability to read/write raster-based formats is of no use to you. But you are right in that the dependency on jpeg should probably be left in, as that is a quite basic dependency.
The changes I am proposing make this customization less painful as you only need to change one parameter for any given dependency.
I agree that we should concentrate on the options which are really needed; so
the changes are as minimal as possible and we don't decrease spec file
(In reply to Petr Kubat from comment #2)
> For example, were you to use gdal in a MySQL Docker image you probably will
> not need support for either PostgreSQL or SQLite/Spatialite.
Agreed with the minimal image use-case, it will be needed for modularity
stuff most probably (where several modules could have differently built
gdal) even though we are not yet there. OTOH, we should avoid this pain if
possible ... and try to analyze all build options one-by-one:
* PostgreSQL support
It seems this is plugin, and it is statically linked into gdal (as many
others). It seems like ogr/ogrsf_frmts/pg has separate GNUMakefile,
which has 'plugin' target (being able to generate dynamic dlopened
This dynamic plugin is not built nowadays, but potentially it could
be .. To go further, I would need some gdal user to tell what such
change would mean from user POV:
So far it seems that dozens of plugins are blindly (statically)
loaded by OGRRegisterAll() but there's also OGROpen() to
explicitly load dynamic plugin. Can we somehow configure what
plugins are going to be loaded *dynamically* if we built
* Spatialite support
It seems like there's --with-spatialite=dlopen option. That sounds
like really neat way out from Requires hell (but no testing is done
We can not build dynamically, yet. Could this be fixed? In the
meantime it looks like it is worth having rpm-build's '--with'
(%bcond_with is standard way) option.
If we were able to solve the dynamic loading problem, we could have those
plugins sub-packaged so the plugin and all its runtime deps would be
installed on-demand. And rpmbuild --with/--without options could control
whether such sub-package is/is-not built.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.
imo, I don't have any stake in this, but... I think it's a little wasteful to make *every* optional feature toggled on/off this way. Only do it as needed.
For example, I was working bug #1490492 to toggle mysql/poppler features, and then noticed this report.
I'll leave it to maintainer to decide if they're willing to support fully fine-grained options or not (marking FutureFeature)
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.
I don't see the benefit of adding the complexity to the spec file.