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