Re: [libesmtp-devel] Away for a bit

[Brian Stafford <brian stafford uklinux net>]

On Fri, 19 October 17:21 Charles Kerr wrote:
> > I figure there are three options
> > 1) No .spec in the tarball and force RPM builders to make a choice
> >    when they configure
> > 2) .spec which builds OpenSSL dependent RPM
> > 3) .spec which builds RPM without dependencies.
> >
> > As I see it
> >
> > 1) is least convenient but the result is always the expected one
> > 2) is best but has dependencies
> > 3) is most convenient but omits useful functionality
> 
> How many projects do releases without RPMs?  I have to admit
> I'm surprised that there aren't RPMs on the libesmtp home page.

The only time I ever use RPM is when installing a new system.  Most of my 
software is built from source.  But then I've been a Unix user since Linus 
wore short pants :)

> Most people just don't build from tarballs.  My preference would
> be to have options 2 and 3 on the esmtp page:
> 
>    * source.tar.gz (100K, source code)
>    * source.tar.bz2 (89K, source code)
>    * RPM - basic (123K, minimum dependencies)
>    * RPM - full (140K, ssl support, etc)
>    * [Debs, etc.]

I'd prefer to have package maintainers do the RPMs and debs for me.  Someday 
I'll get around to linking to them.  CVS would be good, but UK Linux don't 
provide that, at least not yet.  (Sourceforge do obviously but they are in the 
US and I'm a proud European writing crypto support into libESMTP ;)

> I do have a couple of questions about libesmtp from the past week.
> They probably just show my ignorance, but what the heck:
> 
> 1. If ssl is only used for md5, and we've already got md5 in
>    libesmtp, then why are we looking for ssl and adding it as a
>    dependency by default?

It provides the STARTTLS support for opportunistic crypto in SMTP too.  
STARTTLS provides hop by hop security which is sometimes useful, e.g. it 
protects the message envelope from passive attack.  Look in smtp-tls.c, I 
haven't got round to doicumenting this stuff yet.

> 2. Do we need plugins, and if so, do we have to use libtool for

Yes, for the SASL authentication mechanisms.  I want to be able to add more 
mechanisms without having to reinstall the whole SMTP API - particular benefit 
to statically linked apps.

>    them?  Would glib's dynamic module loading work?  Or could we bundle

Yes, but I don't want a glib dependency instead.  I could have used the 
dl_open etc functions, but they aren't universal.

>    the libtool files we need  I ask this for two reasons:

I must emphasise that libltdl is distributed in the tarball, so apart from the 
crypto code, libESMTP is self contained.  configure has an 
--enable-ltdl-install option.  Perhaps this should be used when building the 
RPM.  I believe there is a way of allowing a static ltdl build too.  Its a 
standard thing added by libtoolize, so I really don't know too much about it.  
I just followed the example of some other libs (pspell was one I looked at).

> 
>    * I can't install Balsa on my Mandrake box from RPMs because of
>      libesmtp's "libltdl.so.0" dependency.  rpmfind can't find Mandrake
>      packages for this, and Mandrake Cooker is still on Balsa 1.1.0.

I presume the .spec.in file can be changed to supply the right configure 
options for creating libltdl.so when creating the RPMs and have them install 
that.  To date I rely on people like Carlos and Cristophe for the RPM stuff - 
I've had a steep enough learning curve with auto*/libtool etc etc.  All 
patches gratefully received. (In fact the recent changes in libESMTP have 
mostly been build related.)

In Balsa's case, I thought that pspell depended on libltdl, so I figured it 
should be around anyway.

>      Requiring users to compile code is a terrible idea.

No argument there.  But then again libESMTP is virtually a one man show as far 
as the code and build goes.  The code was the easy bit, a portable build has 
been a time consuming pain and I don't have much free time.  If it weren't for 
Carlos Morgado there'd be no RPMs at all, he can't know how much that is 
appreciated.

>    * Both Pan and Balsa already require glib, which does module loading.
>      developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html
>      has the scoop...

No.  I don't mind depending on libtool since this is supposed to be integrated 
with the auto* tools.  I don't want a glib dependency at all.  Right now 
libESMTP will install anywhere given the right configure options (i.e. 
--enable-ltdl-install).  A major design objective of libESMTP is that it could 
be used in any system, in particular, one with no GUI toolkits or related 
stuff.

Brian Stafford