[BUG] gpgme_data_new_from_filepart() broken since gpgme 0.4.5

[Marcus Brinkmann]

At Mon, 22 Mar 2004 19:54:02 +0100,
> The problem occurs at least with YellowDog Linux (kernel 2.4.25) and with  
> Debian Sid. Is this related to the largefile patch introduced with 0.4.5,  
> which would be an EXTREMELY bad thing as it's appparently plain unusable  
> out of the box? Or any ideas???

Likely the LFS change.  Read the NEWS entry carefully, it explains all
the details.

If you are compiling a GPGME program against 0.4.5, you MUST use
largefile support.

I disagree that this is "EXTREMELY bad".  Some programs that used LFS
were broken with GPGME 0.4.x where x <= 4.  This was now fixed in
0.4.5.  However, in return, now some programs that were not compiled
with LFS are broken now.  "Some programs" means all programs that use
one of the GPGME interfaces that use off_t, in this case
gpgme_data_new_from_filepart.  Supporting both types of programs is
very, very difficult.  We figured that the majority of applications
already use LFS, and that the number of program using the off_t using
interfaces is small anyway.

If this is just a theoretical situation, I am not going to worry about
it.  However, I suspect that you did not find this problem by
exploring corner conditions.  If there is an actual application which
you found was broken after an update to GPGME 0.4.5, you just need to
recompile it with largefile support.  For applications like balsa this
is already be the case, isn't it?

For distributions, which sometimes have to worry about upgrades and
compatibility, I have reserved a special soname that can easily be
activated to let both versions of the library coexist during the
transition.

Without knowing more about the real world problem you are facing,
that's all I can say.  It's all in the NEWS entry, too, with some more
details.

Thanks,
Marcus