On Wed, 01 Apr 2009, Toshio Kuratomi wrote:
1) Port the application to the latest version of libvmime. If
libvmime-0.9 has bugs, get those bugs fixed/patched against that
version. This is part of Fedora's mission to push open source forward.
Well, porting isn't that easy, as libvmime seemingly got really massive and
huge code changes including rewrites and the API (is according to the
developers) completely incompatible between 0.7 <-> 0.8 <-> 0.9, thus
not just some code moving or similar but also a heavy rewrite of the mail
client using the libvmime.
2) Use the -release flag to libtool in order to add 0.7 to the SONAME
the library _ and ship that as libvmime0.7-0.7.1.
3) Change the name of the library to reflect that this isn't the same as
the trunk vmime (like, libfoo-vmime)
Personally, I don't want to fork libvmime. More or less that already has
been done by the patches. But the guys who've written the patches are not
really interested in maintaining soname, API etc. as they just require the
patched libvmime to get their mail client doing what they need to do. On
the other hand, the original libvmime has a public API, soname and all that
So why can't I just put the patched libvmime in the same mail client
package, build it there static at the beginning and afterwards link the
mail client against it? Again, as it's anyway a patched libvmime, it looks
like nothing except the mail client seems to be able to use the library...
Note that I checked upstream for vmime:
and their sourceforge page as well. There's no links to 0.7.1 and 0.8.0
was released in 2005. This tells me that using vmime-0.7.1 is a very
bad idea unless you explicitly fork.
As written above, it is already more or less a fork, but the guys don't see
any real need to rename or much interest to maintain API, soname etc. For
them it just works with their own more or less forking-patches currently.