On Tue, 2016-06-28 at 00:26 +0200, deloptes wrote:
I noticed there is no package for stretch - for jessie and sid there
one - what are the plans or what is the story?
This is also version 1.4.99 - why not 1.5.1 (I mean at least sid)?
I think it had to be removed because it no longer compiled in stretch.
1.5.1 needs to be uploaded, then it can migrate to stretch again.
I also did not understand how I can get the TDE backends into the
syncevolution code tree, or what you would advise to do with backends that
target specific desktop environment (TDE)?
I think it would be best to include it in the upstream release. Then it
is easier for distros to enable it, if they want. OTOH, if a distro
wants, they can already now grab the SyncEvolution source, add the
backend directory from a separate archive or location, and compile both
But there's one unsolved problem either way: distros most likely use the
glib D-Bus bindings. It is the more modern solution. When enabling the
TDE backend, distros would have to use the same workaround as you did
and switch back to the libdbus-based bindings. Not sure whether that's a
viable long term solution.
There are couple of options and I have no idea what is the best way.
team could provide packages, or it could go through the supported distros.
What would you advise?
Here is reference to TDE: http://www.trinitydesktop.org/
Are there distros which include TDE or is the normal approach to use the
packages prepared by the TDE team for certain distros?
If TDE is not included in a distro and SyncEvolution is, then the distro
can't compile the TDE backend. In that case the TDE team could try to
compile the backend against the SyncEvolution version provided by the
distro, but that's tricky - I'm not even sure whether distros install
all the header files, and a custom makefile would have to be written for
Another alternative would be to provide SyncEvolution packages as part
of TDE, overriding the ones provided by the distro. That's also not a
good solution and something that I am currently struggling with in the
project, because for example, Ubuntu has non-upstream patches and
SyncEvolution must be compiled exactly as chosen by Ubuntu, otherwise
the replacement would not work as the original, distro-provided
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.