Re: [Evolution-hackers] Request for adding version information to libcamel soname

[Harish Krishnaswamy <kharish novell com>]

Hi �stein and Heikki,

 My hearty wishes to both of you, the new Debian Evolution package
maintainers :-). Looking forward to work with you towards a better
'Evolution' for the world at large.

 On the bigger point, I am in favor of your suggestion on the versioning
scheme for Camel. On finer thoughts, I would like to evaluate the likely
impact of this change with the mail hackers, keeping in mind any likely
changes to the API during the current development cycle as well as the
compatibility constraints on existing deployments.

I will get back to you in a couple of days.

Thanks,
Harish

On Sun, 2006-04-23 at 23:43 +0200, �stein Gisn�wrote:
> The Debian Evolution Maintainer Team is planning the upload of Evolution
> 2.6 to unstable to happen very soon. Before the upload, we'd like
> feedback from Evolution developers on the biggest change we make to the
> upstream release. In specific, Harish confirmed bug #321372, which is
> what this is about, and also Parthasarathi probably have valuable
> comments on this topic.
> 
> The first part of the change was described in the previous mail in this
> thread. In addition to using version numbers to libcamel (contrast to
> today's 0:0:0), we plan on moving the private libcamel provider
> libraries to an install location that is version specific. The current
> location is /usr/lib/evolution-data-server-1.2/camel-providers/, which
> includes the API version, but not libcamel version. As far as I know, it
> has already been discussed to name the e-d-s directory differently. Do
> you have an update on if/when that will happen? What we will do on the
> debian side is to move the contents of camel-providers to
> camel-providers/8, or alternatively name it camel-providers-8 or
> similar.
> 
> We highly value having the same names and versions in our releases as in
> upstream. If you could give some indications on what changes will be
> made upstream, and what names and versions will be used for this, we
> could use that name/version scheme already and avoid future conflicts.
> 
> Our release will not be delayed indefinitely, but we'll put effort into
> avoiding a diversion from upstream directions. Therefore a quick answer
> will be greatly appreciated.
> 
> Thanks,
>