Bug 434635 - Using incorrect upstream
Using incorrect upstream
Product: Fedora
Classification: Fedora
Component: libical (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Debarshi Ray
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 428925
  Show dependency treegraph
Reported: 2008-02-23 12:17 EST by David Nielsen
Modified: 2008-09-06 13:30 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-09-06 13:30:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Nielsen 2008-02-23 12:17:08 EST
Description of problem:
It turns out Citadel is not the current upstream for libical as was presumed
during the review.

The correct upstream on which Citadel' copy is developed can be found here.

Please consider changing vendors.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Jakub 'Livio' Rusinek 2008-02-23 15:10:52 EST
nothing's wrong in here.

libical was forked many times.

in review I was pleased to change source. I've changed.

why should I change sources AGAIN and make my osmo broken and also other app,
which name I do not remember?
Comment 2 David Nielsen 2008-02-23 16:18:20 EST
I apologize for the length of the following.

a few reasons spring to mind:

A) All distros packaging the same version will drive that to become the defacto
standard (see below for a summary of the most used distros shipped libical) 

B) The previous upstream maintainers has explictedly handed maintainership over
to this group of developers. Thus they are assumed to be the maintainers of the
one true upstream, we should bolster and support the decision of the previous
maintainers instead of continuing a divisive support of a fork.

C) Upstreams such as Bongo are more likely to cease bundling their own copy of
libical in favor of this solution, an overall gain for users and developers.
This however is depended on them being able to rely on the ABI/API compatible
libical being present on most distros. 

Fedora should help in this drive the adoption of the one true upstream for
libical. In the long run it would serve you best as well, it would give you a
place we know has active development to which you could send bugs and it would
be one that in it being used by all distributions you should see patches make
their way upstream instead of each distributions turning their package into a
small fork.

I know I advised a switch to Citadel during your review, mainly because I was at
that time informed that it was the accepted upstream. Additional research and
communication with several people has revealed that this is not the case. I do
apologize for that, it was however the advice I had to give at the time as
Fedora guidelines do strive to keep us as close to upstream as possible, given
the information available to me at the time that seemed to be the best thing.

I urge you to consider switching to the freeassociation libical for these reasons.

For reference:
Major distros using freeassociation libical:




Foresight / rPath Linux:

Major distros using citadel libical:


(they will however get the freeassociation one next time they sync with Debian
at the start of their new cycle)

Sabayon / Gentoo:

Linux Mint:
This is an Ubuntu based distro, but they have been talking about switching their
base to Fedora. Regardless they will move with Ubuntu into the freeassociation
column for the same reason Ubuntu will or go with whatever their new base uses
should they elect to switch base distros. 

Major distributions using other libical implementations:


(http://www.aurore.net/projects/libical/ - discontinued fork which is now handed
over to citadel, meaning they ship unsupported and outdated software.
Additionally libical only shipped as an extra package, they will need to switch
come their 2008 release - if you switch I promise to make it my mission to at
least have them consider freeassociation as their replacement)

That should cover the most used distros, a strong trend of using freeassociation
or moving to it eventually can be seen. At the beginning of the Intrepid Ibex
Ubuntu development cycle (roughly 3-4 months and Hardy release date + 6 months
for public availability in a distro release), this will lead to only Gentoo and
PCLinuxOS having a none freeassociation libical due Ubuntu syncing up with
Debian proper and the change thus spreading to the derived distros. Gentoo and
PCLinuxOS should thus be easy to convince to switch to supporting one upstream I
will personally see to that they at least hear the arguments at least.
Comment 3 Jakub 'Livio' Rusinek 2008-02-23 16:33:19 EST
Test if osmo builds against freeassociation's libical and tell me that.

I have no time for such experiments.
Comment 4 David Nielsen 2008-02-23 16:58:40 EST
The updated libical spec and srpm can be found here:

SPEC: http://dnielsen.fedorapeople.org/libical.spec
SRPM: http://dnielsen.fedorapeople.org/libical-0.30-1.fc9.src.rpm

I tested osmo on my x86_64 machine running rawhide and it compiled without
complaints, it starts and functionality is complete (to the best of my knowledge
having never used osmo before - it works just the same on my machine as your
original package at least).
Comment 5 Jakub 'Livio' Rusinek 2008-02-23 17:08:35 EST
If so, you can put this into CVS, because I was thinking about such ability earlier.

Not sure if "others" can build that packages, but you're free to try.
Comment 6 David Nielsen 2008-02-23 17:33:27 EST
Thank you, I have checked this into development and build a package. As this
seems to be API compatible but not ABI compatible with Citadels libical any
packages depending on libical will need to be recompiled. 

Thus I am not recommending building this for F8/7 till we see if there is any
fall out.

Build is koji here:
Comment 7 Jakub 'Livio' Rusinek 2008-02-23 17:41:03 EST
So osmo would be built against "mine" libical in < F-9, while bongo cannot not
be available for > F-9.

Not so bad.
Comment 8 David Nielsen 2008-02-23 17:53:52 EST
well provided nothing breaks in development we are free to push the new libical
and any packages that depend on it to F8/7, but since the current libical works
and this is both a switch to another source base and a version bump.. I am
tending to favor caution for now and dogfood it a bit.

Eventually we will probably benefit from just having one libical (basically less
code for you to support), but there is no hurry - it can simmer for a few weeks
in development first. There we can allow for a little breakage, once any
breakage has been sorted out we can push everything to updates-testing in one go
- thus avoiding users having broken packages.
Comment 9 David Nielsen 2008-02-24 10:12:54 EST
uour osmo package is the only one currently depending on libical according to
repoquery. I've issued a rebuild for Devel so it doesn't silently break for anyone.

Comment 10 Jakub 'Livio' Rusinek 2008-02-24 10:17:33 EST
Thanks for all your work (I was too lazy).

You did everything, but it doesn't matter, 'cause we both work on the same :) .

Resolving as RAWHIDE.
Comment 11 David Nielsen 2008-02-24 10:22:37 EST
I'd like to keep this one open till we have the same libical in all the repos.
At least if this is open and someone for some reason should build a new package
against libical in both F7/8 and devel they will find a bug explaining why
different versions and vendors are used.

I'd love to see the new libical pushed to stable after it has been dogfooded a
bit in devel, as osmo is the only user currently it would be nice if you beat
the living daylights out of it once the new package hits the repo.

Comment 12 David Nielsen 2008-04-01 02:09:55 EDT
Jakub, this has been simmering in Rawhide for a while, if you haven't done so
already then rebuilding using the rawhide spec on F-7/8 and the deps it might
carry (your osmo is the only one) might be a good move, though depending on if
you have seen any problems with it.
Comment 13 Jakub 'Livio' Rusinek 2008-04-01 09:42:41 EDT
I'm not using Osmo, because after packaging I noticed that it's not what I 
wanted, however I can maintain it for some time, until I get something more 

You think rebuilding Osmo might be now a good idea? Let's update todo list ;) .
Comment 14 David Nielsen 2008-04-01 09:59:01 EDT
I say we sync the development libical package for F-7 and F-8, then issue
rebuilds of apps that depend on it to avoid the ABI change.

Comment 15 Bug Zapper 2008-05-14 01:35:48 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 16 Debarshi Ray 2008-07-16 17:52:33 EDT
(In reply to comment #6)

> Thank you, I have checked this into development and build a package. As this
> seems to be API compatible but not ABI compatible with Citadels libical any
> packages depending on libical will need to be recompiled. 
> Thus I am not recommending building this for F8/7 till we see if there is any
> fall out.

Looks like libical-0.30 does not have the timezone information provided by the
older versions (Citadel ones?) in Fedora 8, and Osmo (when started from the
terminal) throws a warning about this.
Comment 17 Debarshi Ray 2008-07-26 04:03:36 EDT
Got a patch to fix the Osmo problem.
Comment 18 Debarshi Ray 2008-09-06 13:30:53 EDT
Libical has been updated to version 0.32 from Freeassociation on Fedora 8,9 and Rawhide. Osmo has been patched to use this version of Libical.

Note You need to log in before you can comment on or make changes to this bug.