[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