Bug 1415157

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
readability unnecessarily.

(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
      plugin).

      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
        'ogr_PG.$(SO_EXT)' extension?

  * 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
      ATM).

  * SQLite
      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.