Bug 479954 - temporarily disabled syncml support in osmo to fix broken deps
temporarily disabled syncml support in osmo to fix broken deps
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: osmo (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Debarshi Ray
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-14 04:50 EST by Alex Lancaster
Modified: 2009-04-13 02:34 EDT (History)
5 users (show)

See Also:
Fixed In Version: 0.2.4-5.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-13 02:34:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alex Lancaster 2009-01-14 04:50:04 EST
Currently osmo-0.2.4 is broken in rawhide because syncml in rawhide has been bumped to 0.5.0, and osmo version 0.2.4 doesn't support the new API.

I disabled syncml support temporarily in rawhide until such time the osmo bindings are syncml are ported to the new API to fix the broken deps:

	osmo-0.2.4-2.fc11.i386 requires libsyncml.so.0
Comment 1 Alex Lancaster 2009-01-14 04:58:23 EST
I took the liberty of rebuilding osmo in rawhide:

http://koji.fedoraproject.org/koji/buildinfo?buildID=78453

This fixes the broken deps, but this bug should probably be kept open until such time as an osmo with updated API for syncml is released.
Comment 2 Alex Lancaster 2009-01-22 04:46:42 EST
Is it possible to re-add syncml 0.5.0 support?  Looking at osmo upstream SVN:

http://osmo-pim.svn.sourceforge.net/viewvc/osmo-pim/trunk/

it doesn't look like there is a version with support for the new 0.5.0 API in the works.
Comment 3 Alex Lancaster 2009-01-22 04:52:01 EST
I'm actually a little annoyed at the libsyncml maintainer who bumped the soname / API without checking what packages depended on it and whether they had been ported to the new API.  He then tried pushing updates to F-10 and F-9 which would have caused major dep breakage in released version:

http://admin.fedoraproject.org/updates/F9/FEDORA-2009-0540

Thankfully he unpushed them.
Comment 4 Felix Kaechele 2009-01-22 05:09:28 EST
Hi there. I'm very sorry to have annoyed you. I was not aware of the consequences my update had as it worked for me. Since I'm a very new contributor I have learned my lesson from this.
I will revert rawhide to the old version as soon as I find time to do so.

The reason for bumping to 0.5.0 was that I wanted to import blueZync (http://bluezync.kaarposoft.dk/) which requires to have a newer lib.

Sorry again.
Comment 5 Alex Lancaster 2009-01-22 05:25:49 EST
(In reply to comment #4)
> Hi there. I'm very sorry to have annoyed you. I was not aware of the
> consequences my update had as it worked for me. Since I'm a very new
> contributor I have learned my lesson from this.

It's OK, we all make mistakes.  Actually I think your sponsor should probably have taken more time to explain the need to run repoquery to check dependent packages and so on.

> I will revert rawhide to the old version as soon as I find time to do so.

Actually, please don't do that for the moment, since you would have to introduce an Epoch tag, which is a pain, otherwise 

libsync-0.5.0 will never be updated to libsync-0.4.x

see:  https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Version

for more details.

One possible solution (especially if libopensync-plugin-syncml and osmo aren't likely to update to the new API soon) is to introduce a compat-libsyncml-0.4.x version for the old apps to build against and keep libsyncml at 0.5.0, see:

http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages

> The reason for bumping to 0.5.0 was that I wanted to import blueZync
> (http://bluezync.kaarposoft.dk/) which requires to have a newer lib.

OK, thanks for the clarification.
Comment 6 Debarshi Ray 2009-01-22 05:29:51 EST
(In reply to comment #4)
> I will revert rawhide to the old version as soon as I find time to do so.

No need to do that right now. Can you try and port Osmo to the new version? That would be much more constructive and interesting thing to do. Otherwise I will give it a try when I get some time.
Comment 7 Kevin Kofler 2009-03-21 16:35:06 EDT
2 months passed, osmo has still no syncml support and libopensync-plugin-syncml also doesn't build against the new version. I think libsyncml should be reverted with an Epoch bump, I see no other solution. There isn't a single package which can use the version 0.5.0 so it is completely useless.
Comment 8 Till Maas 2009-03-22 07:08:10 EDT
(In reply to comment #7)
> 2 months passed, osmo has still no syncml support and libopensync-plugin-syncml
> also doesn't build against the new version. I think libsyncml should be
> reverted with an Epoch bump, I see no other solution. There isn't a single
> package which can use the version 0.5.0 so it is completely useless.  

libopensync-plugin-syncml-0.38 would build against libsyncml 0.5.0.
Comment 9 Felix Kaechele 2009-03-22 07:13:05 EDT
(In reply to comment #8)
> libopensync-plugin-syncml-0.38 would build against libsyncml 0.5.0.

I am aware of this and contacted the maintainer on 8.3.2009 regarding this issue and haven't received an answer yet.
Comment 10 Kevin Kofler 2009-03-22 16:11:11 EDT
> libopensync-plugin-syncml-0.38 would build against libsyncml 0.5.0. 

1. Are you sure? It says "SET ( LIBSYNCML_MIN_VERSION "0.4.7" )" and appears to have no code to handle 0.5.0 at all.
2. libopensync-plugin-syncml-0.38 does not build against libopensync 0.36 which is what Rawhide has now, it needs at least 0.37 (major API changes between 0.36 and 0.37).
Comment 11 Till Maas 2009-03-23 03:32:06 EDT
(In reply to comment #10)
> > libopensync-plugin-syncml-0.38 would build against libsyncml 0.5.0. 
> 
> 1. Are you sure? It says "SET ( LIBSYNCML_MIN_VERSION "0.4.7" )" and appears to
> have no code to handle 0.5.0 at all.

Yes, it is also mentioned in the release notes. The packages I built used 0.5.0.

> 2. libopensync-plugin-syncml-0.38 does not build against libopensync 0.36 which
> is what Rawhide has now, it needs at least 0.37 (major API changes between 0.36
> and 0.37).  

The libopensync-* packages are afaics synchronized and should all build when they area all updated. The API changes are expected to happen, because it is a development release and this is clearly stated by upstream.
Comment 12 Juha Tuomala 2009-03-24 06:53:27 EDT
libsyncml.so.0 was last time used in 0.4.7.

Then it was bumped to so.2 which is current API. It's a stable release, so why not include it into Fedora if at the same time taking care that apps depending on old API will find their dependencies elsewhere?

What you guys *could* do, is to communicate with the upstream. They *are* in IRC and mailing lists and available, every day, they speak english.

The draft 0.3x libopensync version should not be kept in upcoming fedora releases. They should have never been included into fedora.

IMO whole opensync should be dropped until there will be something that works, gets released and is *supported* by the upstream. 0.22 is not that, it may work for someone but mostly it doesn't. It's definitely not supported by the upstream. That's just a can of worms waiting to get opened in f10/f11 release lifespan.

Tuju
Comment 13 Alex Lancaster 2009-03-24 17:08:14 EDT
(In reply to comment #12)
> libsyncml.so.0 was last time used in 0.4.7.
> 
> Then it was bumped to so.2 which is current API. It's a stable release, so why
> not include it into Fedora if at the same time taking care that apps depending
> on old API will find their dependencies elsewhere?

Reverting to the old API is what is probably going to happen see the thread here:

http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01272.html

and also this post:

http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01359.html
Comment 14 Juha Tuomala 2009-03-25 04:51:09 EDT
I'm subscribing the list.

You're going to do that compatibility package at some point anyway, the way you're doing it just going to introduce the epoch for good. If someone is planning to use 0.5.0 for her project or to create testing packages for Fedora from opensync for example, installing those pkgs will be harder for testers.

Regarding those mails, I'm wondering were you get these opinions "opensync 0.22 works pretty well"? One of the loudest commentor in this topic for example doesn't even have anything to try with (phone/pda).

Note that *copying* your vcards from phone to dekstop pim once doesn't qualify as syncing. You can do that also with kdepim dir resource and libsyncml cli tools without msynctool/osynctool. Problems start when you fall into slowsync and comparison fails, creates duplicates etc. It's not working for the most users. If it would, there wouldn't be a major breakage in trunk, just small enhancements.

Speaking of supported 0.22 branch, cstender did the last change in svn at 21.08.2008, the one bigger set before that was 4.11.2007. This is year 2009. I don't call it supported. Find a developer in upstream who commits to spend time with that (other than holding your hand in irc) and I agree that it's supported. It's not, it's dead.
Comment 15 Debarshi Ray 2009-04-13 01:06:38 EDT
Since libsyncml support has now been re-enabled in Osmo, can we close this as RAWHIDE now.
Comment 16 Alex Lancaster 2009-04-13 02:34:30 EDT
(In reply to comment #15)
> Since libsyncml support has now been re-enabled in Osmo, can we close this as
> RAWHIDE now.  

Done.  Koji build for reference:

http://koji.fedoraproject.org/koji/buildinfo?buildID=96279

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