'database.cc' is becoming a monster, and it's hard to follow what the
various static functions are used for. It turns out that about 1/3 of
this file notmuch_database_add_message and helper functions not used
by any other function. This commit isolates this code into it's own
file.
Some side effects of this refactoring:
- find_doc_ids becomes the non-static (but still private)
_notmuch_database_find_doc_ids
- a few instances of 'string' have 'std::' prepended, avoiding the
need for 'using namespace std;' in the new file.
We have a steady trickle of people using notmuch-emacs from melpa with
distro packages of notmuch, and then being confused when it doesn't
work. Try to warn people what a foot-gun this is; this commentary
should be copied to the melpa web site.
This is likely not strictly necessary given that notmuch-emacs is a
transitional package. But having a simple consistency until we
eventually remove the transitional notmuch-emacs package seems ok too,
and fewer arbitrary lintian warnings will make real lintian warnings
more visible.
Some things that might be interesting (and are acceptable and
supported under 4.0.0, though not required) are:
* supporting DEB_BUILD_OPTIONS tag nodoc wihle tagging build-deps (we
could put python-sphinx into <!nodoc>, for example)
* splitting out Build-Depends-Arch from Build-Depends
The problem shows up on 32 bit architectures where sizeof(time_t) !=
sizeof(gint64). Upcasting the 32 bit time_t to a 64 bit integer
should hopefully be safe.
gmime 3.0 knows how to select the correct GMimeCryptoContext
automatically, so a bunch of the code in notmuch can be dropped in
that case.
The #ifdef removal of the crypto stuff is better than #define aliasing
in gmime-extra.h for this stuff. When built against gmime 3.0:
* it reduces compiled code, and
* it avoids initializing unused gpgme contexts
(based on a patch from dkg)
There are some cases like remote usage where this might cause
problems, but those users can easily customize the variable. The
inconvenience seems to be outweighed by the security benefit for most
users.
When compiling as C code (instead of C++) against gmime 3.0, gcc gives
errors like the following:
error: invalid conversion from ‘int’ to ‘GMimeDecryptFlags’ [-fpermissive]
so use explicit *_NONE values instead.
gmime 3.0 no longer offers a means to set the path for gpg.
Users can set $PATH anyway if they want to pick a
differently-installed gpg (e.g. /usr/local/bin/gpg), so this isn't
much of a reduction in functionality.
The one main difference is for people who have tried to use "gpg2" to
make use of gpg 2.1, but that isn't usefully co-installable anyway.
The reply-to munging code might behave differently whether there's an
exact match on the strings or not, or whether the string is a raw
addr-spec instead of an name-addr. These tests cover those variations
(i also had to tweak json output further below when this new test was
added).
The "key_id" field seems to used for userid in gmime-3.0, while the
keyid is dropped in the fingerprint field if the full fingerprint is
not available.
