[BUG] gpgme_data_new_from_filepart() broken since gpgme 0.4.5

[Marcus Brinkmann]

At Mon, 22 Mar 2004 22:05:40 +0100,
Albrecht Dreß wrote:

> [1  <text/plain; ISO-8859-1 (quoted-printable)>]
> The real world problem (of which the test app is a heavyly stripped down  
> example) *is* indeed balsa.
> 
> The situation is that balsa needs gpgme 0.4.3 or above. People upgraded a  
> debian sid package from 0.4.3 to 0.4.5 (apparently 0.4.4 is not  
> available), resulting in the described problems. This is of course against  
> the whole philosophy of package management. The increase in the patchlevel  
> id is a little small to indicate *what* might go wrong here! So maybe move  
> gpgme 0.4.5 to 0.5.0?

The versioning of the package has absolutely _zero_ to do with ABI
and/or API compatibility.

With every version, we are maintaining the libtool version numbers,
usually properly and to the book.  This time it was an exception,
because we felt that nobody would probably be affected.  So, we have
been wrong by this.  Exactly for this reason I have reserved a special
soname and instructions how to use it, so that distributions can do
the right thing if needed.

I am writing the NEWS file entries for a reason.  They are the first
thing everybody should read directly after unpacking the source and
just before anything else.  My part of the deal is that I list all
important changes in that file - for that I expect that people take
that seriously.  This goes double for distribution maintainers.

> Even worse, recompiling did not help. So the statement in NEWS that LFS  
> support is commonplace for Gtk+-2.0 seems to be wrong (I must admit that I  
> ignored this section due to this... shame on me!).

I meant recompiling with LFS support enabled (for your application).
If that does not fix it, then that would be a genuine bug.  I have to
admit that I did not really check if LFS is enabled/required by
default for Gtk/Gnome.  It certainly is for Qt.  Now that you point it
out, it might very well be that I just assumed that Gtk/Gnome require
LFS, because it's the only sensible option today.

I just googled up this link:
http://ac-archive.sourceforge.net/largefile/gtk2.html

Irregardless of their idea what the right thing to do is wrt library
interfaces for LFS, they certainly get one thing right: That LFS is
enabled.  So, if this is consistently done in all Gtk and Gnome
libraries, enabling it in balsa should be a no-brainer (but watch out
for other libraries you use - if you are exchanging file descriptors
with them, or they use off_t in their interface, they also must be
compiled with LFS support enabled - if you don't exchange fds or use
off_t, it doesn't matter).  You just add the AC_SYS_LARGEFILE macro to
your configure.ac.

Apparently, you can find a script that checks the library dependencies
for mismatches on http://ac-archive.sourceforge.net/largefile/.  I'd
suspect it would be suspect to false positives under certain
conditions, but it's definitely a starting point.

> Adding largefile support to balsa *may* be an option, but as it is a  
> complex project, I have no idea if it breaks other things. Maybe it's  
> better to try finding a workaround for lfs functions...

You really must enable LFS support.  There is as of today absolutely
no valid reason to not enable LFS support in all libraries and
applications on systems where this is supported.  It's the only way to
go.  Of course, you must do this consistently.  The danger (and
problem) is in mixing non-LFS and LFS code that exchanges file
descriptors, or uses off_t.  GPGME does both.

Supporting LFS and non-LFS programs in a library is theoretically
possible, but almost impossible to do correctly in reality, because
it's a very finicky problem.  We don't have the resources to do that
(I investigated this option in detail).  If somebody wants to
implement and maintain transparent non-LFS support, we might include
this support.  However, note that there is a high barrier for what I
consider a correct support of the non-LFS case.

The first thing you should look at is using LFS with balsa.

If distributions want to allow a seamless upgrade (even within things
like the Debian unstable distribution), they can use the reserved
soname and/or --disable-largefile to do that.  I know how
distributions work, and I am confident that all configurations can be
supported if you want that.  If anybody needs help in figuring out
how, all he needs to do is to ask.

My personal recommendation to the Debian maintainer would be to
recompile balsa with LFS support, though, and accept that some users
of Debian unstable will have a broken balsa if they upgrade only gpgme
and not balsa.  The new gpgme package could even conflict with the
older balsa to force an upgrade (IIRC).

> P.S.: I asked the list about a problem with non-blocking gpgme_wait() a  
> few days ago. Any ideas about that? Again ignoring the obvious? ;-))

Only could take a short look at it so far, and didn't find the problem
immediately.  Needs a closer look.

Thanks,
Marcus