Feature request #1586
status of QGIS SONAMEs
Status: | Closed | ||
---|---|---|---|
Priority: | Low | ||
Assignee: | Jürgen Fischer | ||
Category: | Build/Install | ||
Pull Request or Patch supplied: | Resolution: | fixed | |
Easy fix?: | No | Copied to github as #: | 11646 |
Description
On the basis of a brief discussion about Qgis 1.0.x libraries this is
the current point of view by Debian packagers about the status of
Qgis SONAMEs.
Currently 1.0.1 uses
Core library:
SONAME libqgis_core.so.1.0
Non-core that depends on core:
SONAME libqgis_gui.so.1.0
SONAME libqgispython.so.1.0
Plugins that depends on core/non-core:
SONAME libcoordinatecaptureplugin.so
SONAME libcopyrightlabelplugin.so
SONAME libdelimitedtextplugin.so
SONAME libdelimitedtextprovider.so
SONAME libdxf2shpconverterplugin.so
SONAME libgeorefplugin.so
SONAME libgpsimporterplugin.so
SONAME libgpxprovider.so
SONAME libgridmakerplugin.so
SONAME libinterpolationplugin.so
SONAME libmemoryprovider.so
SONAME libnortharrowplugin.so
SONAME libogrconverterplugin.so
SONAME libogrprovider.so
SONAME libpostgresprovider.so
SONAME libquickprintplugin.so
SONAME libscalebarplugin.so
SONAME libspitplugin.so
SONAME libwfsplugin.so
SONAME libwfsprovider.so
SONAME libwmsprovider.so
Now, someone said that API for 1.x is frozen, but ABI could change at every
release, i.e. 1.1 would break 1.0 ABI compatibility (is that confirmed?).
That justifies the use of a 1.0 versioning of SONAMEs, but implies that
debian/control uses the wrong name for libqgis*, which should be libqgis1.0
currently instead and libqgis1.1 for Qgis 1.1.x.
It is due to avoid problems with selective upgrades and third-parties
plugins (it is considered a serious bug FYI, because violates Debian
Policy).
If ABI could change for each patchlevel, 1.x.y should be used in SONAMEs,
and package names should change as consequence. So what's definitively
required is fixing a roadmap for API/ABI changes, and following it,
in order to allow distributors doing their work and avoid problems
to other developers and users.
Same considerations apply to Python interface per se, IF both
API and/or ABI changes could be expected independently on the C++ interfaces
(e.g. if python interfaces changed more rapidly).
In that case python related packages should declare their interface level,
to avoid dangerous mixing with compiled objects. At least currently it is
NOT expected on the basis of current package style. But is this true?
Those are currently the major blockers to even think of having Qgis in
Debian again. A well-defined policy need to be stated and followed.
History
#1 Updated by Paolo Cavallini over 14 years ago
- Resolution set to fixed
- Status changed from Open to Closed
Now QGIS is in debian. Is this ticket still valid?