Hi fellow hackers, With reference to Bug 380534 on clarifying Evolution's library requirements, I am putting down my thoughts and recommendations here and will be proposing this in the weekly evolution meeting (#evolution-meet on irc.gimp.org at 1000 UTC 6 Dec 2006) tomorrow. Comments/questions welcome, as always.
I see two aspects of the problem described in the bug that merit two separate approaches : a. Inbound Dependencies - The libraries that Evolution/EDS/Evolution Exchange depend on. b. Outbound Dependencies - Dependencies that EDS libraries provides to other applications that are based on or integrated with Evolution/EDS. 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. I feel it is important that we move away from i) the use of deprecated APIs from various GNOME libraries to the improved, maintained versions. ii) Evolution specific widgets/thread/mutex/data structures implementation that are now available in generic GNOME libraries. This is possible now in some cases (EList->GList, EThread->GThread, EMutex->GMutex?) but not all (ETable, ETree). This ensures we take advantage of the newer capabilities available and make it easier for contributors to continue adding value to our project. However, it is also true that a very large number of our users (enterprise, organizations, ISVs) still live on older GNOME Desktop environments (Gtk <= 2.6), willing to upgrade specific applications (Evo) but not their entire Desktop every six months. I think this would be the case in future too that the 'majority' of the installed base stays a step or two behind the Bleeding-Edge/State-Of-The-Art Latest releases. If-defs and conditional compilations with significant addition to the maintenance complexity are a necessity to support such users who need to move to newer versions without overhauling their desktop. It is fair IMHO, however, for individual distributions to handle them according to their needs, rather than the upstream maintaining a super-set of everybody's constraints. I wish to propose an exception to the above if and only if when an inbound dependency is likely to cause a change to an outbound dependency as discussed in (b). On (b) Outbound dependencies, and this is specially relevant to bugs like 373117, where we would like to preserve the binary compatibility of outbound libraries (libebook and libecal, in particular, which are the heavily used ones and as well as various Camel/Calendar/Addressbook providers built on EDS) and take care that any changes do not trigger massive upgrade overheads for those who consume our libraries. Evolution has learnt this the hard way, erred on some and handled them with additional code overheads in other cases. 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). 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. (There has also been a separate discussion on the need to get Evolution's Camel library versioned and promise a compatible interface for foreseeable future and Varadhan is already working on this with other mail hackers). 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 ?) The Answer : Patch and Testing love [hint...hint ;-)] Thanks, Harish _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers