Re: [Evolution-hackers] RFC: Evolution's library requirements

[Matthew Barnes <mbarnes redhat com>]

I'll respond here since I may not be up in time for the 6 a.m. meeting
tomorrow.  Great feedback overall, just have a few comments.


On Wed, 2006-12-06 at 00:51 +0530, Harish Krishnaswamy wrote:
> On (a) Inbound Dependencies, 
> 
> I suggest that on upstream CVS, Evolution  should depend on the most
> recent stable versions of the libraries available in the corresponding
> GNOME release (Evolution 2.9.x/2.8.x on GNOME 2.16, 2.6.x on GNOME
> 2.14). This is similar but not exactly the same as what Matthew has
> outlined in Bug 380534. I agree that the configure scripts need to
> hard-enforce these dependencies while building the packages.

Did you mean Evolution 2.9.x/2.10.x on GNOME 2.16?  Or will Evolution
2.10.x (which should essentially be 2.9.92 plus bug fixes) suddenly
depend on GNOME 2.18?

I think it makes more sense for the development and _subsequent_ stable
releases to share the same library requirements.  The requirements can
then be bumped when the next development cycle starts (after CVS is
branched).  So, for example, 2.11.x/2.12.x will depend on GNOME 2.18.

I agree that depending on the libraries provided by the most recent
_stable_ GNOME release is the right thing to do.


> On (b) Outbound dependencies, 

> Here, I would recommend that we extend the APIs rather than
> modify/delete them and mark the deprecated functions (to be discarded
> after a specified and sufficient timeline) so that they do not get used
> in newer code.  These libraries need to support older environments (and
> possibly deprecated library calls) in a broader sense than in case (a). 

I recommend we start tagging deprecated functions in EDS the same way
most other GNOME libraries do:

   #ifndef EDS_DISABLE_DEPRECATED

   /* ... deprecated declarations ... */

   #endif

It makes the deprecated symbols easy to track, they can be disabled at
compile time to ensure we're not using them internally, and GTK-Doc has
a hook for automatically generating deprecation warnings in the
documentation when this method is used.


> In these cases, some conditional compilation and #ifdef hacks will have
> to be supported on the upstream as well. I wish I could specify hard
> numbers on minimum dependencies for various libraries here. ( Is
> 'Libraries corresponding to GNOME 2.14' a good one ?) but I do not have
> the answers yet. If you have a POV that you feel must be considered,
> please do let me know or join us in the meeting tomorrow.

It's these minimum dependencies that need to get encoded in the
configure script, so we do need to decide on hard numbers.  I believe
GNOME 2.14 shipped GTK+ 2.8, so we'll have to go back further than that
if users are still relying on GTK+ <= 2.6.  Can they upgrade individual
libraries though, such as GLib?


> I also feel the library dependencies are best conveyed by the build
> tools and our decisions should be reflected in and enforced by our
> pkg-config and configure scripts.  (remember the recurring NSS/NSPR ,
> LDAP/NTLM issues ?) 

I'd still like to see at least the policy (if not the specific library
requirements) documented on go-evolution.org for reference, especially
for the sake of new contributors.  And it wouldn't hurt to add a section
about this to the HACKING file.


Matthew Barnes