[libical] ABI stability

[Patrick Ohly]

On Sat, 2013-11-23 at 19:57 +0100, Patrick Ohly wrote:
> On Sat, 2013-11-23 at 10:12 -0500, Allen Winter wrote:
> > But this was a major release, so reasonable and not unexpected for ABI to break in a major release.
> 
> I agree, if there are good reasons for an ABI break, then doing it at a
> major release is the right thing to do. But that doesn't mean that a
> major release alone is a reason for breaking the ABI.
> 
> > Of course we need to find a way to ensure ABI.
> 
> Good.
> 
> > Now I worried that ABI is broken again for people who rebuilt against 1.0.0
> > and then install the next release.  So I'm thinking of reverting 1156
> 
> And restore the previous behavior where the ABI was essentially
> undefined, because it was depending on the implementation of Perl? That
> doesn't sound like a solution.
> 
> I had checked, Ubuntu Saucy has libical.so.1 with enums sorted, just
> like Fedora has now. I suggest declaring that as the libical.so.1 ABI
> and ensuring that all users of libical 1.0 adhere to that; therefore a
> bugfix release with commit 1156 would be good.

Do we agree that libical.so.1 uses the ABI with sorted enums and that
therefore all distros should compile libical 1.0 with commit 1156
included?

I'm copying kubuntu-devel at lists.ubuntu.com, the maintainers of libical
in Ubuntu, to ensure that they are aware of this issue.

BTW, I was wrong when I said earlier that no relevant changes happened
between libical.so.0 and libical.so.1 as far as SyncEvolution was
concerned. Inserting ICAL_ACKNOWLEDGED_PROPERTY at the beginning of the
icalproperty_kind enum changed values that SyncEvolution uses, so I'll
have to add further hacks to keep the same binary working with dlopened
libical.so.1 and libical.so.0.

-- 
Bye, Patrick Ohly
--  
Patrick.Ohly at gmx.de
http://www.estamos.de/