Bug 498837

Summary:	Release of libvmime to EPEL-5
Product:	[Fedora] Fedora EPEL	Reporter:	Jeroen van Meeuwen <vanmeeuwen+fedora>
Component:	libvmime	Assignee:	Jeroen van Meeuwen <vanmeeuwen+fedora>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	el5	CC:	mastahnke, redhat-bugzilla, vanmeeuwen+fedora
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	ActualBug
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-02-08 15:12:18 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	498194

Description Jeroen van Meeuwen 2009-05-03 20:24:43 UTC

Release of libvmime to EPEL-5, as a requirement for zarafa, zarafa-webaccess and zarafa-webaccess-mobile.

Needs to be version 0.7.x, and requires a number of patches. See also: http://www.zarafa.com/wiki/index.php/Libvmime_patches

Comment 1 Robert Scheck 2009-05-03 23:49:09 UTC

Questions and points are:

 - How to name the package? compat-libvmime? libvmime07? I would tend to the
   first one, because Zarafa 6.40.0 will likely use libvmime 0.8.x rather the
   currently used 0.7.x, thus we could easily upgrade (not another review and
   somehow really nothing except Zarafa depends on that old library).
 - How to change the soname? Original one is libvmime.so.0.7.1, but has an 
   overlap with libvime.so.0.9.0 at libvmime.so.0 unluckily - but 0.7 and 0.9
   are API and ABI incompatible; IMHO worse upstream handling. Ideas?
 - Need to check, which of the Zarafa patches are backports and which of them
   have been accepted by upstream. For the rest Zarafa and we should try to
   get them upstream.

Comment 2 Robert Scheck 2009-05-03 23:51:54 UTC

Note: I got told, that libvmime 0.7, 0.8 and 0.9 are ABI/API incompatible,
so upstream would have missed two major soname version bumps. Maybe somebody
with appropriate knowledge can verify that.

Comment 3 Jeroen van Meeuwen 2009-05-04 01:08:54 UTC

(In reply to comment #1)
> Questions and points are:
> 
>  - How to name the package? compat-libvmime? libvmime07? I would tend to the
>    first one, because Zarafa 6.40.0 will likely use libvmime 0.8.x rather the
>    currently used 0.7.x, thus we could easily upgrade (not another review and
>    somehow really nothing except Zarafa depends on that old library).

Note that Zarafa is the only package in EL that requires libvmime, and thus we can upgrade whenever we want to.

However, Zarafa 6.20(.x), 6.30(.y) and 6.40(.z) will be running production in supported environments. As such, at some point, we'll need to provide both libvmime-0.7.x as well as libvmime-0.8.x (and possibly libvmime-0.9.x).

>  - How to change the soname? Original one is libvmime.so.0.7.1, but has an 
>    overlap with libvime.so.0.9.0 at libvmime.so.0 unluckily - but 0.7 and 0.9
>    are API and ABI incompatible; IMHO worse upstream handling. Ideas?

Working on this.

>  - Need to check, which of the Zarafa patches are backports and which of them
>    have been accepted by upstream. For the rest Zarafa and we should try to
>    get them upstream.  

Working on this as well.

Comment 4 Jeroen van Meeuwen 2009-05-04 08:42:04 UTC

(In reply to comment #3)
> (In reply to comment #1)
> >  - Need to check, which of the Zarafa patches are backports and which of them
> >    have been accepted by upstream. For the rest Zarafa and we should try to
> >    get them upstream.  
> 
> Working on this as well.  

6 patches are known not to be upstream (yet).

For a full list of patches applicable to libvmime-0.7.1 see http://git.kanarip.com/?p=vmime;a=tree;f=contrib/zarafa;hb=762ad2187847af1eac3909d4fecb794fe78252e0

Note that the patches listed above may or may not have been accepted/committed/released by upstream already, just not for 0.7.1, or I've not found them yet. This directory will have less and less patches as I work on this.

Another directory holds the patches that have *definitely* been accepted/committed/released by upstream, http://git.kanarip.com/?p=vmime;a=tree;f=contrib/upstream-backports;hb=762ad2187847af1eac3909d4fecb794fe78252e0 This directory will have more and more patches as I work on this.

Overall, I believe there's like 7 or 8 patches that need to go upstream.

Comment 5 Robert Scheck 2010-02-08 15:12:18 UTC

I would say this has been solved with bug #521352.