[Fedora-packaging] How to package a patched older version of libvmime in Fedora best?

Toshio Kuratomi a.badger at gmail.com
Wed Apr 1 19:04:04 UTC 2009


Robert Scheck wrote:
> Good evening,
> 
> I've the situation, that a package unluckily requires an older version of
> libvmime and some specific/individual patches as well. The question is now,
> how to package that best for Fedora and EPEL?
> 
> What I'm requiring is libvmime 0.7.1 + patches, while upstream is at 0.9.1
> which is unluckily ABI and API incompatible.
> 
> There are now multiple solutions how to deal with this as I can't use 0.9.1
> now and in foreseeable future:
> 
> a) Build libvmime 0.7.1 + patches in before of the software requiring it
>    and link statically against it. This would make sense in this case, even
>    if static linking is discouraged in Fedora, but nothing except that
>    piece of software requires actually libvmime 0.7.1 + individual patches.
> 
> b) Build libvmime 0.7.1 + patches as own package and call it e.g. something
>    like foobar-libvmime and rename libvmime.so.* to foobar-libvmime.so.* or
>    similar. That would bring me to -lfoobar-libvmime linking or something
>    similar, right?
> 
> Just providing a compat-libvmime seems not suitable, as compat-* in Fedora
> is only providing the library, not -devel stuff which is actually needed to
> build the other software requiring the old libvmime 0.7.1 + patches.
> 
> As of overlapping *.so filenames, it is not possible to avoid renaming the
> patched version. Question is, which is better and which one will go through
> the package review or are there better ideas how to solve this?
> 
> Yes, some far day, upstream will accept all of the individual patches and
> the other software will support latest libvmime version, but this won't be
> in the next time as libvmime support is somehow seemingly less interested
> in being backward compatible.
> 

In general, my order of preference would be:

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.
2) Use the -release flag to libtool in order to add 0.7 to the SONAME of
the library [1]_ 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)

Note that I checked upstream for vmime: http://www.vmime.org/download/
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.

If you're willing to fork and become upstream for the new library, I'd
recommend taking route #2 (if upstream will let you distribute your
fixed copies from the vmime.org website/sourceforge pages) or #3 if
you're going to start competing with vmime.

.. _[1]:
http://www.gnu.org/software/libtool/manual/html_node/Release-numbers.html#Release-numbers

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/packaging/attachments/20090401/e354135f/attachment.bin 


More information about the packaging mailing list