[BUG] gpgme_data_new_from_filepart() broken since gpgme 0.4.5

[Marcus Brinkmann]

At Thu, 25 Mar 2004 23:21:39 +0100,
Jose Carlos Garcia Sogo wrote:
>   Please, could you CC updates on this directly to the Debian bug
>   #239453 that has been filed on gpgme0.4 package? I need to be sure 
>   that it doesn't break anything.

I have two additional comments to make which are not in the Debian BTS yet.

First, another option, at least for now, is to use the reserved soname
in GPGME to compile GPGME without LFS support using the current
soname, and with LFS support using the new reserved soname.  Then you
must ensure that all applications that are broken with GPGME without
LFS support are (re)compiled with GPGME with LFS support.  This is the
way to go from the book.  There is a catch however: With the next
official soname change, there won't be a reserved soname anymore to
use for non-LFS compiled GPGME (you would have to escape to a library
rename: libgpgme-lfs or whatever).  So, this would only be a temporary
work around.

Second, it is reasonably safe to work around the problem by not using
gpgme_data_new_from_filepart (or the seek callback).  You still have
the issue of mixing file descriptors, but this will work as long as
you don't try to read beyond 2GB in any such file.  As emails over 2GB
are absurd (for the years to come :), it would be a workable solution
for quite a bit of time (so that you can convert balsa to LFS without
a rush).

Thanks,
Marcus