Bug 1415157 - Modify gdal's .spec file to allow for easier management of optional dependencies
Summary: Modify gdal's .spec file to allow for easier management of optional dependencies
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gdal
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Sandro Mani
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-20 12:27 UTC by Petr Kubat
Modified: 2020-12-17 16:01 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-17 16:01:43 UTC
Type: Bug


Attachments (Terms of Use)
Better optional depenedcies management (9.42 KB, patch)
2017-01-20 12:27 UTC, Petr Kubat
no flags Details | Diff

Description Petr Kubat 2017-01-20 12:27:37 UTC
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.

Additional info:

Porposed patch against rawhide attached

Comment 1 Jozef Mlich 2017-01-20 13:30:03 UTC
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?

Comment 2 Petr Kubat 2017-01-20 14:26:53 UTC
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.

Comment 3 Pavel Raiskup 2017-02-17 11:01:57 UTC
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.

Comment 4 Fedora End Of Life 2017-02-28 11:01:31 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 5 Rex Dieter 2017-09-11 18:43:20 UTC
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)

Comment 6 Fedora Admin user for bugzilla script actions 2020-07-28 14:55:26 UTC
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 7 Sandro Mani 2020-12-17 16:01:43 UTC
I don't see the benefit of adding the complexity to the spec file.


Note You need to log in before you can comment on or make changes to this bug.