New gpgme 0.3 release

[Pawel Salek]

Werner Koch wrote:

> It is unlikely that we will include libgpg-error in gpgme because  
> this is hard to maintain and libgpg-error is used by 4 packages right  
> now.[snip]
> Please use gpgme 0.4.3 etc. if you you can do this without too much
> hassles.

What about including libgpgme in libgpg-error or merging these packages  
in some other way? libgpgme.tar.gz is less than 300kb which is very  
little nowadays. Would it matter for these 4 packages (what are they?).  
Maintainance is definetely an issue but one should remember that the  
programs are made to make life simpler for people and people should not  
make more effort than necessary to get the functionality they want.

I cannot claim I know GPG-related packages very well but I have  
impression the whole design resembles a patchwork and not a good  
engineering work (I put my asbesto suit on now! :). Much better design  
would be to have a single library (call it libgpg) that would come with  
a basic CLI frontend (program called gpg). If one wants to link other  
libraries, one would need to install only some header files and that's  
all. Currently, I need to install not only gnupg but also guess that  
libgpg-error is needed and compile and install gpgme as well. spec  
files contained in gpgme and libgpg-error do not work out of the box on  
RH9.0 - and Fedora as well (I think the problems are rpm-4 related;  
fixing is not difficult but timeconsuming). Prefix is hardcoded to / 
usr. Furthermore, if a stubborn user somehow decides to bite the bullet  
and continues anyway, he/she will discover that his/her favourite  
program suddenly stops with message:

** Message: init gpgme version 0.4.3

** ERROR **: Invalid engine for OpenPGP
aborting...
Aborted

(what does it really mean?) and does not give any chance to continue  
with the encryption support disabled (many programs have GPG support  
not as a main functionality but as an add-on). And this is the release  
recommended for use?

(pressure goes down, asbesto suit is being taken off).

IMO, following changes would make gpgme much more useful for developers  
that want to use PGP encryption/signing in their applications:

1. building process should be simplified. If people have problems  
builing the library, they won't bother porting their programs to it.  
Care should be taken to allow for static linking - very important in  
case of "semi-stable" libraries with changing api. I could provide spec  
files for building gpgme and libgpg-error on RH9.0 if there is any  
interest.

2. if the library initialization fails for some reason so that it  
cannot provide its functionality, it should not abort the whole  
program.

Best regards,

Pawel
--
Pawel Salek, http://balsa.gnome.org/