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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
