RE: Upcoming GMime 3.0 changes
- From: Tomi Ollila <tomi.ollila@xxxxxx>
- To: David Bremner <david@xxxxxxxxxxx>, Daniel Kahn Gillmor <dkg@xxxxxxxxxxxxxxxxx>, Jeffrey Stedfast <jestedfa@xxxxxxxxxxxxx>, "notmuch\@notmuchmail.org" <notmuch@xxxxxxxxxxxxxxx>
- Date: Tue, 09 May 2017 23:02:48 +0300
On Tue, May 09 2017, David Bremner wrote:
Daniel Kahn Gillmor <dkg@xxxxxxxxxxxxxxxxx> writes:
out of curiosity, why do you think we won't be able to drop gmime-2.6
for a few years? if it's due to the debian release cycle and wanting to
backport notmuch to stretch, i don't think i'd mind providing backports
of gmime 3.0 for that purpose.
That was what I was thinking about (and other distros with similar
release cycles). But even among our own developers I don't know we can
just throw a switch and say "install gmime 3.0 before you git pull".
I personally can compile gmime 3.0 for this (EOL'd) scientific linux 6.2
machine where I am writing this email, provided it does not need c/c++11
features(*). If gmime-3.0 could be statically linked to notmuch binary then
we could even provide an option to have it bundled into notmuch when
compiled (like I've included zlib...).
I guess the other point is even with backports, there is still the issue
of security support for older releases. We'll need to maintain the 2.6
stuff in a branch, even if it only gets security/severe bug updates.
But these go to releases (how many old of those) which still have support
for gmime 2.6...
Another question is how long Jeff plans to support 2.6 with bug fixes.
d
Tomi
(*) I compiled Xapian 1.4 for Fedora 25; compiled fine and notmuch worked
with it. On SL6.2 compilation failed, and when running
/opt/rh/devtoolset-2/root/usr/bin/gcc compilation crashed at some point,
Other related posts:
