On Fri, 27 Nov 2009 22:22:01 -0800, Carl Worth <cworth@cworth.org> wrote:
> On Fri, 27 Nov 2009 21:28:03 -0600, "Jeffrey C. Ollie" <jeff@ocjtech.us> wrote:
> > Instead of including a private implementation of the SHA1 hash, use
> > libgcrypt.  This means less code of our own to maintain and it will be
> > easier to switch to a different hash function like SHA256.
> 
> I don't believe we have a significant code-maintenance burden with
> libsha1.c. And as for different hash functions, the only use of sha-1 in
> notmuch is as a fallback in the case of a message not including a
> Message-ID header.
> 
> So I don't see it as important at all to try to remove this code.

Its good that this is not a burden to maintain for the notmuch project,
even better that Mikhail, the libsha1 maintainer, is currently active in
this project and has volunteered to maintain the in-tree copy. 

However, the problem that has been raised is about the code-maintenance
burden that distributions face. In fact, this is not an unique problem
to notmuch, if it was it wouldn't be such a big deal. The reality is
that the more projects which cargo-cult around 'convenience copies' of
code, the more of a burden is placed on the distributors.

In some ways, the notmuch project and the role of distributors are at
cross-purposes on this issue, each side has an argument that makes sense
From their individual perspectives.

> > libgcrypt was chosen because it has a fairly simple API, it's well
> > tested (it's used in gnutls and gnupg2), and it's licensed under the
> > LGPL.
> 
> What might make more sense is an option to compile against an existing
> library (if present) but not to introduce an error in the build if the
> library is not present, (in which case just build the builtin libsha1.c
> code).

This makes the most sense, and resolves the issue in a way that both
sides of the issue benefit!

> But if that wouldn't solve the problem you were trying to solve, (to
> actually remove libsha1.c), then maybe we don't need to do anything for
> now?

I think from a distribution point-of-view, if you are providing a
mechanism to link against libgcrypt, while still maintaining this
embedded code-copy for convenience's-sake, actually removing libsha1.c
is not so necessary. It does mean an exception must be noted on the
distribution side that indicates that although this code exists, its not
being used, but that is a negligible burden.

micah