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

[Tim Sutton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

Thanks for your useful insights - we would love to see QGIS in debian
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.

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

> 
> 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



- --

Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==============================================
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Visit http://linfiniti.com to find out about:
 * QGIS programming and support services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
==============================================

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknL7kkACgkQqk07qZdiYjdYpACZATh9vw7IiKvA/iwHW+ijfEuS
6J8AnA9Qygxly15IzhKLNlb6jztlj6zR
=w7Pl
-----END PGP SIGNATURE-----