[Qgis-developer] Request of statement about qgis libraries.

[Francesco P. Lovergine]

On Thu, Mar 26, 2009 at 11:06:24PM +0200, Tim Sutton wrote:
> standard repos. See below for responses:
> 
> Francesco P. Lovergine wrote:
> > Hi folks
> > 
> > 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?). 
> 
> Yes that is correct. Our stable branch will undergo maintenance for at
> least the next year with bug fix only releases producing 1.0.x versions.
> 
> The 1.x releases will be marked as unstable always and will not be
> recommended for users wishing to emphasise stability consistency (e.g.
> in enterprises where support needs to be offered).
> 
> The API of 1.x releases are expected to remain backwards compatible for
> the foreseeable future but as we head towards version 2.0 we could
> expect that API may undergo changes too.
> 
> I think it is safe to assume that in all cases we cannot guarantee ABI
> compatibility since even a small bug fix that requires adding a new
> class member or changing the static designation of a member variable
> could break ABI compatibility.
> 

So for the future I would expect something like

SONAME               libqgis_core.so.1.0.1

for all core libs. Note that, if people distributed svn-taken
pre-releases, at least at package level you should add 'Provides:
qgis-interface-1.0.1-N' to avoid breakages. All third-parties depending
packages should depend on that. I'm going to modify d-gis provided tree
in order to show that. The N level should be upgraded for each new
snapshot. This would allow for instance distributing a third parties
source and binary plugin depending on qgis-interface-1.0.1-0. I hope
this is clear enough.

> > 
> > 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.
> 
> Ok we can work to change this to use the 1.x.y versioning scheme - I
> dont see any problem conceptually with that - others like Juergen could
> probably offer better insight as to whether this presents us with any
> technical issues.
> 
> 
> > 
> > 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?
> 
> Martin could probably comment better than I here but I would expect the
> python libs to closely track the API of core an gui. That said bug fixes
> could always break thinks. Having python libs link to an explicit
> library could help to prevent issues like this:
> 
> https://trac.osgeo.org/qgis/ticket/1548 (other issues aside).
> 

You can rely on the (= ${binary:Version}) dependency for that in the
qgis package. What is needed is depending on qgis-interface-X.Y.Z
at release time for other packaged plugins (or -N in case
of snapshots). This is not currently the case, but it could be
possible in the future, that's the reason for the Provides: item.

> > 
> > 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.
> > 
> 
> Thanks for the input - we will continue trying to get our project debian
> compliant into the future.
> 
> Regards
> 

-- 
Francesco P. Lovergine