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.
Greetings,
Robert