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
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#Re...
-Toshio
On Wed, 01 Apr 2009, Toshio Kuratomi wrote:
- 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.
Well, porting isn't that easy, as libvmime seemingly got really massive and huge code changes including rewrites and the API (is according to the developers) completely incompatible between 0.7 <-> 0.8 <-> 0.9, thus it's not just some code moving or similar but also a heavy rewrite of the mail client using the libvmime.
- 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)
Personally, I don't want to fork libvmime. More or less that already has been done by the patches. But the guys who've written the patches are not really interested in maintaining soname, API etc. as they just require the patched libvmime to get their mail client doing what they need to do. On the other hand, the original libvmime has a public API, soname and all that stuff.
So why can't I just put the patched libvmime in the same mail client package, build it there static at the beginning and afterwards link the mail client against it? Again, as it's anyway a patched libvmime, it looks like nothing except the mail client seems to be able to use the library...
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.
As written above, it is already more or less a fork, but the guys don't see any real need to rename or much interest to maintain API, soname etc. For them it just works with their own more or less forking-patches currently.
Greetings, Robert
On 04/02/2009 02:11 PM, Robert Scheck wrote:
As written above, it is already more or less a fork, but the guys don't see any real need to rename or much interest to maintain API, soname etc. For them it just works with their own more or less forking-patches currently.
This is great until there is a security issue or a bug fix that doesn't make into this copy.
The "toss random patches against old versions of libraries and carry them forever" is a plan for disaster. We shouldn't be encouraging it.
~spot
On Thu, 02 Apr 2009, Tom spot Callaway wrote:
This is great until there is a security issue or a bug fix that doesn't make into this copy.
Okay, as per our talk in IRC, I will use app-libvmime or libvmime-app as package name and thus play with the -release possibility of libtool to get libvmime soname changed.
[20:18:22] < rsc> spot: that's worse argumenting IMHO ;) [20:18:39] < rsc> spot: if it's "officially" forked, same can happen anyway. [20:19:14] < spot> rsc: yes, but in those cases, upstream is usually making other changes and there is less likelyhood of overlap in issues [20:19:29] < spot> (it's also less obvious to l33t hax0rs) [20:20:54] < rsc> spot: as upstream is focussed to rewriting code and API from 0.x to 0.x+1, I guess, upstream less cares about current 0.x-2 [20:21:34] < rsc> spot: means, I'm in doubt regarding whether security fixes (if there's one) really a) applies and b) is relevant at all. [20:22:39] < spot> rsc: again, since it would be buried in a dependent package, no one will know to look until it is too late. [20:22:58] < spot> the correct answer is "port it to the current library" [20:23:19] < spot> the slightly acceptable compromise answer is "rename the library, make it standalone" [20:23:46] < rsc> spot: and who will do that huge amount of work again and again for every 0.x+1 release of upstream? [20:24:21] < spot> coding is hard, lets go shopping. [20:24:40] < rsc> spot: second thing means forking in other words, right? [20:24:58] < spot> rsc: upstream forked the moment they decided to bundle a patched library. [20:25:12] < spot> you'd just be making a more managable, visible fork. [20:25:29] < rsc> spot: "just", exactly. [20:25:57] < rsc> spot: okay, that means, I better should simply go for libvmime0.7.so.0.7.1? [20:26:25] < spot> rsc: sure. [20:26:39] < spot> rsc: as a separate package, preferrably. [20:27:50] < rsc> spot: okay. Any suggestions how to %{name} the package? libvmime07? [20:28:22] < spot> well, given that it has specific patches for one app, i might incorporate the name of that app [20:28:34] < rsc> spot: okay, so app-libvmime? [20:30:54] < spot> rsc: or libvmime-app [20:32:03] < rsc> spot: any opinion which is better? AFAIK we not really have a guideline for that. Personally I would tend to app-libvmime to make visible where it belongs to. But I can life with both. [20:32:26] < spot> i wouldn't lose sleep over either honestly. [20:32:32] < spot> your call [20:33:05] < rsc> okay, then I'll throw a dice, once I come to that.
Greetings, Robert
On Thu, 2009-04-02 at 14:13 -0400, Tom "spot" Callaway wrote:
On 04/02/2009 02:11 PM, Robert Scheck wrote:
As written above, it is already more or less a fork, but the guys don't see any real need to rename or much interest to maintain API, soname etc. For them it just works with their own more or less forking-patches currently.
This is great until there is a security issue or a bug fix that doesn't make into this copy.
Well, not much of an issue if it has a caring and responsive maintainer. The Security Response team tracks also embedded and old copies and notifies their maintainers. There's no chance of fixing the security issue with "dumb luck" of bumping the package to newer release but I suspect that's nothing we want to rely on anyways.
The "toss random patches against old versions of libraries and carry them forever" is a plan for disaster. We shouldn't be encouraging it.
I can imagine that sticking to earlier release can be quite logical reaction when upstream keeps changing the API incompatibly. I don't know anything about this specific case though.
(Oh,by the way, I remember porting balsa to newer version of some gnome mime library a couple of weeks ago. If this is the same library; they provide a shell script that tries to do most of the changes automatically. I discovered it when I was done with my patch... I could still verify. Anyways, if this is it, it might help you)
On Fri, 2009-04-03 at 03:50 -0700, Toshio Kuratomi wrote:
Lubomir Rintel wrote:
Well, not much of an issue if it has a caring and responsive maintainer. The Security Response team tracks also embedded and old copies and notifies their maintainers.
Curious: How do you track embedded versions?
Hm, looking at the fedora security CVS seems like my memories are fading since I left SRT.
I was sure there was a file that lists known embedded versions of software packages within others, but I can't find it. Probably it was internal to Red Hat CVS. We've also been having an OpenGrok instance, which is no longer maintained at the time. That was pretty handy to find copied code anywhere.
So... it might be that I was wrong -- I can't really say now SRT reliably tracks embedded copies of code. Current SRT members may know better.
On 03/28/2009 01:41 PM, Robert Scheck wrote:
Yes, some far day, upstream will accept all of the individual patches
If upstream is not accepting patches, that calls to question whether we want to include this software at all... May I ask what specific package you are trying to include that refuses to use a newer libvmime?
packaging@lists.fedoraproject.org
-
Christopher Aillon -
Lubomir Rintel -
Robert Scheck -
Tom Callaway -
Toshio Kuratomi