libgmime installation and build requirements

[Matthias Andree]

On Wed, 11 Dec 2002, Scott Lenser wrote:

> > I'm not in favor of libgmime:
> > 
> > * It's oversized.
> >   We don't need the encoding stuff.
> >   We don't need uudecode.
> >   We don't need signature handling.
> > 
> 
> True, we don't need the encoding stuff.  OTOH, the fact that I don't need
> every widget known to man doesn't keep me from using GTK.
> 
> Greg has found instances of uuencoded attachments show we do need
> uudecode.

We do not need uudecode: uuencoded text is not presented to the reader.
We already agreed that we're not decoding binary parts, so why do we
need uuencode now?

If anything, we need "super tokens" which weigh more in the calculation-
I'm not sure if we're doing that already, but the word "click" is
certainly more indicative of spam than "the" is. Do current algorithms
weigh tokens by their entropy?

> > * I cannot build 2-current from CVS, it's inconsistent at best, old
> >   libtool fails to build shared library, new libtool/automake break the
> >   build altogether.
> > 
> 
> I'm not sure why you are having so much trouble.  I just had to install
> libglib-2.0 and dev package and was able to build and install with no
> problems.

The binary package, yes, but I wonder how they managed to build it. I
could not.

> > * Why does it need glib to build if it doesn't use it at run time?
> 
> It uses glib at runtime.  It's listed in the ldd output for my version
> which uses libgmime.

Not with mine (which is pretty suspicious. dlopen magic? I haven't
traced it.)

> What gory dependencies?  It depends on libc6 (for iconv) and glib-2.0
> (which lots of other stuff depends on).

Yes, and glib-2.0 is not widely deployed now. 2004 might be time for
glib-2; it takes time for these new libraries to propagate to
distributions. Once glib-2 applications mature, glib-2 will be
omnipresent. It's not now, in fact, of the machines I look after, one has
glib-2...

-- 
Matthias Andree